httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: cvs commit: apache/htdocs/manual/misc known_client_problems.html
Date Sun, 20 Jul 1997 22:15:24 GMT
Any additions/corrections/comments?  I dug through the archives to come up
with the byteranges entry here, I think I summarized everything. 


On Sun, 20 Jul 1997, Dean Gaudet wrote:

> dgaudet     97/07/20 14:26:48
>   Added:       htdocs/manual/misc  known_client_problems.html
>   Log:
>   First draft of all the problems we know about and have worked around...
>   Revision  Changes    Path
>   1.1                  apache/htdocs/manual/misc/known_client_problems.html
>   Index: known_client_problems.html
>   ===================================================================
>   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
>   <HTML>
>   <HEAD>
>   <TITLE>Apache HTTP Server Project</TITLE>
>   </HEAD>
>   <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
>   <BODY
>    TEXT="#000000"
>    LINK="#0000FF"
>    VLINK="#000080"
>    ALINK="#FF0000"
>   >
>   <!--#include virtual="header.html" -->
>   <H1 ALIGN="CENTER">Known Problems in Clients</H1>
>   <p>Over time the Apache Group has discovered or been notified of problems
>   with various clients which we have had to work around.  This document
>   describes these problems and the workarounds available.  It's not arranged
>   in any particular order.  Some familiarity with the standards is assumed,
>   but not necessary.
>   <p>For brevity, <i>Navigator</i> will refer to Netscape's Navigator
>   product, and <i>MSIE</i> will refer to Microsoft's Internet Explorer
>   product.  All trademarks and copyrights belong to their respective
>   companies.  We welcome input from the various client authors to correct
>   inconsistencies in this paper, or to provide us with exact version
>   numbers where things are broken/fixed.
>   <p>For reference,
>   <a href="">RFC1945</a>
>   defines HTTP/1.0, and
>   <a href="">RFC2068</a>
>   defines HTTP/1.1.  Apache as of version 1.2 is an HTTP/1.1 server (with an 
>   optional HTTP/1.0 proxy).
>   <p>Various of these workarounds are triggered by environment variables.
>   The admin typically controls which are set, and for which clients, by using 
>   <a href="../mod/mod_browser.html">mod_browser</a>.  Unless otherwise
>   noted all of these workarounds exist in versions 1.2 and later.
>   <a name="trailing-crlf"><H3>Trailing CRLF on POSTs</H3></a>
>   <p>This is a legacy issue.  The CERN webserver required <code>POST</code>
>   data to have an extra <code>CRLF</code> following it.  Thus many
>   clients send an extra <code>CRLF</code> that
>   is not included in the <code>Content-Length</code> of the request.
>   Apache works around this problem by eating any empty lines which
>   appear before a request.
>   <a name="broken-keepalive"><h3>Broken keepalive</h3></a>
>   <p>Various clients have had broken implementations of <i>keepalive</i>
>   (persistent connections).  In particular the Windows versions of
>   Navigator 2.0 get very confused when the server times out an
>   idle connection.  The workaround is present in the default config files:
>   <blockquote><code>
>   BrowserMatch Mozilla/2 nokeepalive
>   </code></blockquote>
>   Note that this matches some earlier versions of MSIE, which began the
>   practice of calling themselves <i>Mozilla</i> in their user-agent
>   strings just like Navigator.
>   <p>MSIE 4.0b2, which claims to support HTTP/1.1, does not properly
>   support keepalive when it is used on 301 or 302 (redirect)
>   responses.  Unfortunately Apache's <code>nokeepalive</code> code
>   prior to 1.2.2 would not work with HTTP/1.1 clients.  You must apply
>   <a href="">this
>   patch</a> to version 1.2.1.  Then add this to your config:
>   <blockquote><code>
>   BrowserMatch "MSIE 4\.0b2;" nokeepalive
>   </code></blockquote>
>   <a name="force-response-1.0"><h3>Incorrect interpretation of <code>HTTP/1.1</code>
in response</h3></a>
>   <p>To quote from section 3.1 of RFC1945:
>   <blockquote>
>   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
>   of the protocol. The protocol versioning policy is intended to allow
>   the sender to indicate the format of a message and its capacity for
>   understanding further HTTP communication, rather than the features
>   obtained via that communication.
>   </blockquote>
>   Since Apache is an HTTP/1.1 server, it indicates so as part of its
>   response.  Many client authors mistakenly treat this part of the response
>   as an indication of the protocol that the response is in, and then refuse
>   to accept the response.
>   <p>The first major indication of this problem was with AOL's proxy servers.
>   When Apache 1.2 went into beta it was the first wide-spread HTTP/1.1
>   server.  After some discussion, AOL fixed their proxies.  In
>   anticipation of similar problems, the <code>force-response-1.0</code>
>   environment variable was added to Apache.  When present Apache will
>   indicate "HTTP/1.0" in response to an HTTP/1.0 client,
>   but will not in any other way change the response.
>   <p>The pre-1.1 Java Development Kit (JDK) that is used in many clients
>   (including Navigator 3.x and MSIE 3.x) exhibits this problem.  As do some
>   of the early pre-releases of the 1.1 JDK.  We think it is fixed in the
>   1.1 JDK release.  In any event the workaround:
>   <blockquote><code>
>   BrowserMatch Java1.0 force-response-1.0 <br>
>   BrowserMatch JDK/1.0 force-response-1.0 
>   </code></blockquote>
>   <p>RealPlayer 4.0 from Progressive Networks also exhibits this problem:
>   <blockquote><code>
>   BrowserMatch "RealPlayer 4.0" force-response-1.0
>   </code></blockquote>
>   <a name="msie4.0b2"><h3>Requests use HTTP/1.1 but responses must be in
>   <p>MSIE 4.0b2 has this problem.  Its Java VM makes requests in HTTP/1.1
>   format but the responses must be in HTTP/1.0 format (in particular, it
>   does not understand <i>chunked</i> responses).  The workaround
>   is to fool Apache into believing the request came in HTTP/1.0 format.
>   <blockquote><code>
>   BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
>   </code></blockquote>
>   This workaround is available in 1.2.2, and in a
>   <a href="">patch
>   </a> against 1.2.1.
>   <a name="257th-byte"><h3>Boundary problems with header parsing</h3></a>
>   <p>All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
>   have a problem if the trailing CRLF of the response header starts at
>   the 256th or 257th byte of the response.  A BrowserMatch for this would
>   match on nearly every hit, so the workaround is enabled automatically
>   on all responses.  The workaround is to detect when this condition would
>   occur in a response and add extra padding to the header to push the
>   trailing CRLF past the 257th byte of the response.
>   <a name="boundary-string"><h3>Multipart responses and Quoted Boundary Strings</h3></a>
>   <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.
>   <a name="byterange-requests"><h3>Byterange requests</h3></a>
>   <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>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>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>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>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.
>   <!--#include virtual="footer.html" -->
>   </BODY>
>   </HTML>

View raw message