rubbos/app/apache2/manual/misc/known_client_problems.html.en

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