1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3 4<html xmlns="http://www.w3.org/1999/xhtml"> 5 <head> 6 <meta name="generator" content="HTML Tidy, see www.w3.org" /> 7 8 <title>Apache HTTP Server Project</title> 9 </head> 10 <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 11 12 <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 13 vlink="#000080" alink="#FF0000"> 14 <div align="CENTER"> 15 <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 16 17 <h3>Apache HTTP Server Version 1.3</h3> 18 </div> 19 20 21 <h1 align="CENTER">Known Problems in Clients</h1> 22 23 <p>Over time the Apache Group has discovered or been notified 24 of problems with various clients which we have had to work 25 around, or explain. This document describes these problems and 26 the workarounds available. It's not arranged in any particular 27 order. Some familiarity with the standards is assumed, but not 28 necessary.</p> 29 30 <p>For brevity, <em>Navigator</em> will refer to Netscape's 31 Navigator product (which in later versions was renamed 32 "Communicator" and various other names), and <em>MSIE</em> will 33 refer to Microsoft's Internet Explorer product. All trademarks 34 and copyrights belong to their respective companies. We welcome 35 input from the various client authors to correct 36 inconsistencies in this paper, or to provide us with exact 37 version numbers where things are broken/fixed.</p> 38 39 <p>For reference, <a 40 href="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</a> 41 defines HTTP/1.0, and <a 42 href="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</a> 43 defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1 44 server (with an optional HTTP/1.0 proxy).</p> 45 46 <p>Various of these workarounds are triggered by environment 47 variables. The admin typically controls which are set, and for 48 which clients, by using <a 49 href="../mod/mod_setenvif.html">mod_setenvif</a>. Unless 50 otherwise noted all of these workarounds exist in versions 1.2 51 and later.</p> 52 53 <h3><a id="trailing-crlf" name="trailing-crlf">Trailing CRLF on 54 POSTs</a></h3> 55 56 <p>This is a legacy issue. The CERN webserver required 57 <code>POST</code> data to have an extra <code>CRLF</code> 58 following it. Thus many clients send an extra <code>CRLF</code> 59 that is not included in the <code>Content-Length</code> of the 60 request. Apache works around this problem by eating any empty 61 lines which appear before a request.</p> 62 63 <h3><a id="broken-keepalive" name="broken-keepalive">Broken 64 keepalive</a></h3> 65 66 <p>Various clients have had broken implementations of 67 <em>keepalive</em> (persistent connections). In particular the 68 Windows versions of Navigator 2.0 get very confused when the 69 server times out an idle connection. The workaround is present 70 in the default config files:</p> 71 72 <blockquote> 73 <code>BrowserMatch Mozilla/2 nokeepalive</code> 74 </blockquote> 75 Note that this matches some earlier versions of MSIE, which 76 began the practice of calling themselves <em>Mozilla</em> in 77 their user-agent strings just like Navigator. 78 79 <p>MSIE 4.0b2, which claims to support HTTP/1.1, does not 80 properly support keepalive when it is used on 301 or 302 81 (redirect) responses. Unfortunately Apache's 82 <code>nokeepalive</code> code prior to 1.2.2 would not work 83 with HTTP/1.1 clients. You must apply <a 84 href="http://www.apache.org/dist/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"> 85 this patch</a> to version 1.2.1. Then add this to your 86 config:</p> 87 88 <blockquote> 89 <code>BrowserMatch "MSIE 4\.0b2;" nokeepalive</code> 90 </blockquote> 91 92 <h3><a id="force-response-1.0" 93 name="force-response-1.0">Incorrect interpretation of 94 <code>HTTP/1.1</code> in response</a></h3> 95 96 <p>To quote from section 3.1 of RFC1945:</p> 97 98 <blockquote> 99 HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to 100 indicate versions of the protocol. The protocol versioning 101 policy is intended to allow the sender to indicate the format 102 of a message and its capacity for understanding further HTTP 103 communication, rather than the features obtained via that 104 communication. 105 </blockquote> 106 Since Apache is an HTTP/1.1 server, it indicates so as part of 107 its response. Many client authors mistakenly treat this part of 108 the response as an indication of the protocol that the response 109 is in, and then refuse to accept the response. 110 111 <p>The first major indication of this problem was with AOL's 112 proxy servers. When Apache 1.2 went into beta it was the first 113 wide-spread HTTP/1.1 server. After some discussion, AOL fixed 114 their proxies. In anticipation of similar problems, the 115 <code>force-response-1.0</code> environment variable was added 116 to Apache. When present Apache will indicate "HTTP/1.0" in 117 response to an HTTP/1.0 client, but will not in any other way 118 change the response.</p> 119 120 <p>The pre-1.1 Java Development Kit (JDK) that is used in many 121 clients (including Navigator 3.x and MSIE 3.x) exhibits this 122 problem. As do some of the early pre-releases of the 1.1 JDK. 123 We think it is fixed in the 1.1 JDK release. In any event the 124 workaround:</p> 125 126 <blockquote> 127 <code>BrowserMatch Java/1.0 force-response-1.0<br /> 128 BrowserMatch JDK/1.0 force-response-1.0</code> 129 </blockquote> 130 131 <p>RealPlayer 4.0 from Progressive Networks also exhibits this 132 problem. However they have fixed it in version 4.01 of the 133 player, but version 4.01 uses the same <code>User-Agent</code> 134 as version 4.0. The workaround is still:</p> 135 136 <blockquote> 137 <code>BrowserMatch "RealPlayer 4.0" force-response-1.0</code> 138 </blockquote> 139 140 <h3><a id="msie4.0b2" name="msie4.0b2">Requests use HTTP/1.1 141 but responses must be in HTTP/1.0</a></h3> 142 143 <p>MSIE 4.0b2 has this problem. Its Java VM makes requests in 144 HTTP/1.1 format but the responses must be in HTTP/1.0 format 145 (in particular, it does not understand <em>chunked</em> 146 responses). The workaround is to fool Apache into believing the 147 request came in HTTP/1.0 format.</p> 148 149 <blockquote> 150 <code>BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 151 force-response-1.0</code> 152 </blockquote> 153 This workaround is available in 1.2.2, and in a <a 154 href="http://www.apache.org/dist/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"> 155 patch</a> against 1.2.1. 156 157 <h3><a id="257th-byte" name="257th-byte">Boundary problems with 158 header parsing</a></h3> 159 160 <p>All versions of Navigator from 2.0 through 4.0b2 (and 161 possibly later) have a problem if the trailing CRLF of the 162 response header starts at offset 256, 257 or 258 of the 163 response. A BrowserMatch for this would match on nearly every 164 hit, so the workaround is enabled automatically on all 165 responses. The workaround implemented detects when this 166 condition would occur in a response and adds extra padding to 167 the header to push the trailing CRLF past offset 258 of the 168 response.</p> 169 170 <h3><a id="boundary-string" name="boundary-string">Multipart 171 responses and Quoted Boundary Strings</a></h3> 172 173 <p>On multipart responses some clients will not accept quotes 174 (") around the boundary string. The MIME standard recommends 175 that such quotes be used. But the clients were probably written 176 based on one of the examples in RFC2068, which does not include 177 quotes. Apache does not include quotes on its boundary strings 178 to workaround this problem.</p> 179 180 <h3><a id="byterange-requests" 181 name="byterange-requests">Byterange requests</a></h3> 182 183 <p>A byterange request is used when the client wishes to 184 retrieve a portion of an object, not necessarily the entire 185 object. There was a very old draft which included these 186 byteranges in the URL. Old clients such as Navigator 2.0b1 and 187 MSIE 3.0 for the MAC exhibit this behavior, and it will appear 188 in the servers' access logs as (failed) attempts to retrieve a 189 URL with a trailing ";xxx-yyy". Apache does not attempt to 190 implement this at all.</p> 191 192 <p>A subsequent draft of this standard defines a header 193 <code>Request-Range</code>, and a response type 194 <code>multipart/x-byteranges</code>. The HTTP/1.1 standard 195 includes this draft with a few fixes, and it defines the header 196 <code>Range</code> and type 197 <code>multipart/byteranges</code>.</p> 198 199 <p>Navigator (versions 2 and 3) sends both <code>Range</code> 200 and <code>Request-Range</code> headers (with the same value), 201 but does not accept a <code>multipart/byteranges</code> 202 response. The response must be 203 <code>multipart/x-byteranges</code>. As a workaround, if Apache 204 receives a <code>Request-Range</code> header it considers it 205 "higher priority" than a <code>Range</code> header and in 206 response uses <code>multipart/x-byteranges</code>.</p> 207 208 <p>The Adobe Acrobat Reader plugin makes extensive use of 209 byteranges and prior to version 3.01 supports only the 210 <code>multipart/x-byterange</code> response. Unfortunately 211 there is no clue that it is the plugin making the request. If 212 the plugin is used with Navigator, the above workaround works 213 fine. But if the plugin is used with MSIE 3 (on Windows) the 214 workaround won't work because MSIE 3 doesn't give the 215 <code>Range-Request</code> clue that Navigator does. To 216 workaround this, Apache special cases "MSIE 3" in the 217 <code>User-Agent</code> and serves 218 <code>multipart/x-byteranges</code>. Note that the necessity 219 for this with MSIE 3 is actually due to the Acrobat plugin, not 220 due to the browser.</p> 221 222 <p>Netscape Communicator appears to not issue the non-standard 223 <code>Request-Range</code> header. When an Acrobat plugin prior 224 to version 3.01 is used with it, it will not properly 225 understand byteranges. The user must upgrade their Acrobat 226 reader to 3.01.</p> 227 228 <h3><a id="cookie-merge" 229 name="cookie-merge"><code>Set-Cookie</code> header is 230 unmergeable</a></h3> 231 232 <p>The HTTP specifications say that it is legal to merge 233 headers with duplicate names into one (separated by commas). 234 Some browsers that support Cookies don't like merged headers 235 and prefer that each <code>Set-Cookie</code> header is sent 236 separately. When parsing the headers returned by a CGI, Apache 237 will explicitly avoid merging any <code>Set-Cookie</code> 238 headers.</p> 239 240 <h3><a id="gif89-expires" 241 name="gif89-expires"><code>Expires</code> headers and GIF89A 242 animations</a></h3> 243 244 <p>Navigator versions 2 through 4 will erroneously re-request 245 GIF89A animations on each loop of the animation if the first 246 response included an <code>Expires</code> header. This happens 247 regardless of how far in the future the expiry time is set. 248 There is no workaround supplied with Apache, however there are 249 hacks for <a 250 href="http://arctic.org/~dean/patches/apache-1.2-gif89-expires-hack.patch"> 251 1.2</a> and for <a 252 href="http://arctic.org/~dean/patches/apache-1.3-gif89-expires-hack.patch"> 253 1.3</a>.</p> 254 255 <h3><a id="no-content-length" 256 name="no-content-length"><code>POST</code> without 257 <code>Content-Length</code></a></h3> 258 259 <p>In certain situations Navigator 3.01 through 3.03 appear to 260 incorrectly issue a POST without the request body. There is no 261 known workaround. It has been fixed in Navigator 3.04, 262 Netscapes provides some <a 263 href="http://help.netscape.com/kb/client/971014-42.html">information</a>. 264 There's also <a 265 href="http://arctic.org/~dean/apache/no-content-length/"> 266 some information</a> about the actual problem.</p> 267 268 <h3><a id="jdk-12-bugs" name="jdk-12-bugs">JDK 1.2 betas lose 269 parts of responses.</a></h3> 270 271 <p>The http client in the JDK1.2beta2 and beta3 will throw away 272 the first part of the response body when both the headers and 273 the first part of the body are sent in the same network packet 274 AND keep-alive's are being used. If either condition is not met 275 then it works fine.</p> 276 277 <p>See also Bug-ID's 4124329 and 4125538 at the java developer 278 connection.</p> 279 280 <p>If you are seeing this bug yourself, you can add the 281 following BrowserMatch directive to work around it:</p> 282 283 <blockquote> 284 <code>BrowserMatch "Java1\.2beta[23]" nokeepalive</code> 285 </blockquote> 286 287 <p>We don't advocate this though since bending over backwards 288 for beta software is usually not a good idea; ideally it gets 289 fixed, new betas or a final release comes out, and no one uses 290 the broken old software anymore. In theory.</p> 291 292 <h3><a id="content-type-persistence" 293 name="content-type-persistence"><code>Content-Type</code> 294 change is not noticed after reload</a></h3> 295 296 <p>Navigator (all versions?) will cache the 297 <code>content-type</code> for an object "forever". Using reload 298 or shift-reload will not cause Navigator to notice a 299 <code>content-type</code> change. The only work-around is for 300 the user to flush their caches (memory and disk). By way of an 301 example, some folks may be using an old <code>mime.types</code> 302 file which does not map <code>.htm</code> to 303 <code>text/html</code>, in this case Apache will default to 304 sending <code>text/plain</code>. If the user requests the page 305 and it is served as <code>text/plain</code>. After the admin 306 fixes the server, the user will have to flush their caches 307 before the object will be shown with the correct 308 <code>text/html</code> type.</p> 309 310 <h3><a id="msie-cookie-y2k" name="msie-cookie-y2k">MSIE Cookie 311 problem with expiry date in the year 2000</a></h3> 312 313 <p>MSIE versions 3.00 and 3.02 (without the Y2K patch) do not 314 handle cookie expiry dates in the year 2000 properly. Years 315 after 2000 and before 2000 work fine. This is fixed in IE4.01 316 service pack 1, and in the Y2K patch for IE3.02. Users should 317 avoid using expiry dates in the year 2000.</p> 318 319 <h3><a id="lynx-negotiate-trans" 320 name="lynx-negotiate-trans">Lynx incorrectly asking for 321 transparent content negotiation</a></h3> 322 323 <p>The Lynx browser versions 2.7 and 2.8 send a "negotiate: 324 trans" header in their requests, which is an indication the 325 browser supports transparent content negotiation (TCN). However 326 the browser does not support TCN. As of version 1.3.4, Apache 327 supports TCN, and this causes problems with these versions of 328 Lynx. As a workaround future versions of Apache will ignore 329 this header when sent by the Lynx client.</p> 330 331 <h3><a id="ie40-vary" name="ie40-vary">MSIE 4.0 mishandles Vary 332 response header</a></h3> 333 334 <p>MSIE 4.0 does not handle a Vary header properly. The Vary 335 header is generated by mod_rewrite in apache 1.3. The result is 336 an error from MSIE saying it cannot download the requested 337 file. There are more details in <a 338 href="http://bugs.apache.org/index/full/4118">PR#4118</a>.</p> 339 340 <p>A workaround is to add the following to your server's 341 configuration files:</p> 342<pre> 343 BrowserMatch "MSIE 4\.0" force-no-vary 344</pre> 345 346 <p>(This workaround is only available with releases 347 <strong>after</strong> 1.3.6 of the Apache Web server.)</p> 348 <hr /> 349 350 <h3 align="CENTER">Apache HTTP Server Version 1.3</h3> 351 <a href="./"><img src="../images/index.gif" alt="Index" /></a> 352 <a href="../"><img src="../images/home.gif" alt="Home" /></a> 353 354 </body> 355</html> 356 357
