known_client_problems.html.en

apache的软件linux版本

    response header starts at offset 256, 257 or 258 of the
    response. A BrowserMatch for this would match on nearly every
    hit, so the workaround is enabled automatically on all
    responses. The workaround implemented detects when this
    condition would occur in a response and adds extra padding to
    the header to push the trailing CRLF past offset 258 of the
    response.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="boundary-string" id="boundary-string">Multipart responses and 
                              Quoted Boundary Strings</a></h2>

    <p>On multipart responses some clients will not accept quotes
    (") around the boundary string. The MIME standard recommends
    that such quotes be used. But the clients were probably written
    based on one of the examples in RFC2068, which does not include
    quotes. Apache does not include quotes on its boundary strings
    to workaround this problem.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="byterange-requests" id="byterange-requests">Byterange Requests</a></h2>

    <p>A byterange request is used when the client wishes to
    retrieve a portion of an object, not necessarily the entire
    object. There was a very old draft which included these
    byteranges in the URL. Old clients such as Navigator 2.0b1 and
    MSIE 3.0 for the MAC exhibit this behaviour, and it will appear
    in the servers' access logs as (failed) attempts to retrieve a
    URL with a trailing ";xxx-yyy". Apache does not attempt to
    implement this at all.</p>

    <p>A subsequent draft of this standard defines a header
    <code>Request-Range</code>, and a response type
    <code>multipart/x-byteranges</code>. The HTTP/1.1 standard
    includes this draft with a few fixes, and it defines the header
    <code>Range</code> and type
    <code>multipart/byteranges</code>.</p>

    <p>Navigator (versions 2 and 3) sends both <code>Range</code>
    and <code>Request-Range</code> headers (with the same value),
    but does not accept a <code>multipart/byteranges</code>
    response. The response must be
    <code>multipart/x-byteranges</code>. As a workaround, if Apache
    receives a <code>Request-Range</code> header it considers it
    "higher priority" than a <code>Range</code> header and in
    response uses <code>multipart/x-byteranges</code>.</p>

    <p>The Adobe Acrobat Reader plugin makes extensive use of
    byteranges and prior to version 3.01 supports only the
    <code>multipart/x-byterange</code> response. Unfortunately
    there is no clue that it is the plugin making the request. If
    the plugin is used with Navigator, the above workaround works
    fine. But if the plugin is used with MSIE 3 (on Windows) the
    workaround won't work because MSIE 3 doesn't give the
    <code>Range-Request</code> clue that Navigator does. To
    workaround this, Apache special cases "MSIE 3" in the
    <code>User-Agent</code> and serves
    <code>multipart/x-byteranges</code>. Note that the necessity
    for this with MSIE 3 is actually due to the Acrobat plugin, not
    due to the browser.</p>

    <p>Netscape Communicator appears to not issue the non-standard
    <code>Request-Range</code> header. When an Acrobat plugin prior
    to version 3.01 is used with it, it will not properly
    understand byteranges. The user must upgrade their Acrobat
    reader to 3.01.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="cookie-merge" id="cookie-merge"><code>Set-Cookie</code> header is
    unmergeable</a></h2>

    <p>The HTTP specifications say that it is legal to merge
    headers with duplicate names into one (separated by commas).
    Some browsers that support Cookies don't like merged headers
    and prefer that each <code>Set-Cookie</code> header is sent
    separately. When parsing the headers returned by a CGI, Apache
    will explicitly avoid merging any <code>Set-Cookie</code>
    headers.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="gif89-expires" id="gif89-expires"><code>Expires</code> headers 
    and GIF89A animations</a></h2>

    <p>Navigator versions 2 through 4 will erroneously re-request
    GIF89A animations on each loop of the animation if the first
    response included an <code>Expires</code> header. This happens
    regardless of how far in the future the expiry time is set.
    There is no workaround supplied with Apache, however there are
    hacks for <a href="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch">
    1.2</a> and for <a href="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">
    1.3</a>.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="no-content-length" id="no-content-length"><code>POST</code> without
    <code>Content-Length</code></a></h2>

    <p>In certain situations Navigator 3.01 through 3.03 appear to
    incorrectly issue a POST without the request body. There is no
    known workaround. It has been fixed in Navigator 3.04,
    Netscapes provides some <a href="http://help.netscape.com/kb/client/971014-42.html">information</a>.
    There's also <a href="http://www.arctic.org/~dgaudet/apache/no-content-length/">
    some information</a> about the actual problem.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="jdk-12-bugs" id="jdk-12-bugs">JDK 1.2 betas lose
    parts of responses.</a></h2>

    <p>The http client in the JDK1.2beta2 and beta3 will throw away
    the first part of the response body when both the headers and
    the first part of the body are sent in the same network packet
    AND keep-alive's are being used. If either condition is not met
    then it works fine.</p>

    <p>See also Bug-ID's 4124329 and 4125538 at the java developer
    connection.</p>

    <p>If you are seeing this bug yourself, you can add the
    following BrowserMatch directive to work around it:</p>

    <div class="example"><p><code>
    BrowserMatch "Java1\.2beta[23]" nokeepalive
    </code></p></div>

    <p>We don't advocate this though since bending over backwards
    for beta software is usually not a good idea; ideally it gets
    fixed, new betas or a final release comes out, and no one uses
    the broken old software anymore. In theory.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="content-type-persistent" id="content-type-persistent"><code>Content-Type</code>
    change is not noticed after reload</a></h2>

    <p>Navigator (all versions?) will cache the
    <code>content-type</code> for an object "forever". Using reload
    or shift-reload will not cause Navigator to notice a
    <code>content-type</code> change. The only work-around is for
    the user to flush their caches (memory and disk). By way of an
    example, some folks may be using an old <code>mime.types</code>
    file which does not map <code>.htm</code> to
    <code>text/html</code>, in this case Apache will default to
    sending <code>text/plain</code>. If the user requests the page
    and it is served as <code>text/plain</code>. After the admin
    fixes the server, the user will have to flush their caches
    before the object will be shown with the correct
    <code>text/html</code> type.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="msie-cookie-y2k" id="msie-cookie-y2k">MSIE Cookie
    problem with expiry date in the year 2000</a></h2>

    <p>MSIE versions 3.00 and 3.02 (without the Y2K patch) do not
    handle cookie expiry dates in the year 2000 properly. Years
    after 2000 and before 2000 work fine. This is fixed in IE4.01
    service pack 1, and in the Y2K patch for IE3.02. Users should
    avoid using expiry dates in the year 2000.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="lynx-negotiate-trans" id="lynx-negotiate-trans">Lynx incorrectly asking for
    transparent content negotiation</a></h2>

    <p>The Lynx browser versions 2.7 and 2.8 send a "negotiate:
    trans" header in their requests, which is an indication the
    browser supports transparent content negotiation (TCN). However
    the browser does not support TCN. As of version 1.3.4, Apache
    supports TCN, and this causes problems with these versions of
    Lynx. As a workaround future versions of Apache will ignore
    this header when sent by the Lynx client.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="ie40-vary" id="ie40-vary">MSIE 4.0 mishandles Vary
    response header</a></h2>

    <p>MSIE 4.0 does not handle a Vary header properly. The Vary
    header is generated by mod_rewrite in apache 1.3. The result is
    an error from MSIE saying it cannot download the requested
    file. There are more details in <a href="http://bugs.apache.org/index/full/4118">PR#4118</a>.</p>

    <p>A workaround is to add the following to your server's
    configuration files:</p>

   <div class="example"><p><code>
    BrowserMatch "MSIE 4\.0" force-no-vary
   </code></p></div>

    <p>(This workaround is only available with releases
    <strong>after</strong> 1.3.6 of the Apache Web server.)</p>

  </div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/misc/known_client_problems.html" title="English">&nbsp;en&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2007 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>
<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>
</body></html>