home *** CD-ROM | disk | FTP | other *** search
/ Chip 2004 November / CMCD1104.ISO / Software / Complet / Apache / apache_2.0.52-win32-x86-no_ssl.msi / Data.Cab / F277897_known_client_problems.html.en < prev    next >
Extensible Markup Language  |  2004-02-20  |  22KB  |  408 lines
  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="<-" alt="<-" src="../images/left.gif" /></a></div>
  18. <div id="path">
  19. <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a> > <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"> en </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 "<MAJOR>.<MINOR>" 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"> en </a></p>
  405. </div><div id="footer">
  406. <p class="apache">Copyright 1999-2004 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>