diff options
Diffstat (limited to 'docs/manual/misc/known_client_problems.html')
| -rw-r--r-- | docs/manual/misc/known_client_problems.html | 305 |
1 files changed, 0 insertions, 305 deletions
diff --git a/docs/manual/misc/known_client_problems.html b/docs/manual/misc/known_client_problems.html deleted file mode 100644 index 4d41fc7707..0000000000 --- a/docs/manual/misc/known_client_problems.html +++ /dev/null @@ -1,305 +0,0 @@ -<!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 - BGCOLOR="#FFFFFF" - 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, or explain. -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, <EM>Navigator</EM> will refer to Netscape's Navigator -product (which in later versions was renamed "Communicator" and -various other names), and <EM>MSIE</EM> 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="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</A> -defines HTTP/1.0, and -<A HREF="ftp://ds.internic.net/rfc/rfc2068.txt">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. - -<H3><A NAME="trailing-crlf">Trailing CRLF on POSTs</A></H3> - -<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. - -<H3><A NAME="broken-keepalive">Broken keepalive</A></H3> - -<P>Various clients have had broken implementations of <EM>keepalive</EM> -(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 <EM>Mozilla</EM> 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="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch" ->this patch</A> to version 1.2.1. Then add this to your config: -<BLOCKQUOTE><CODE> -BrowserMatch "MSIE 4\.0b2;" nokeepalive -</CODE></BLOCKQUOTE> - -<H3><A NAME="force-response-1.0">Incorrect interpretation of -<CODE>HTTP/1.1</CODE> in response</A></H3> - -<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 Java/1.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. -However they have fixed it in version 4.01 of the player, but version -4.01 uses the same <CODE>User-Agent</CODE> as version 4.0. The -workaround is still: -<BLOCKQUOTE><CODE> -BrowserMatch "RealPlayer 4.0" force-response-1.0 -</CODE></BLOCKQUOTE> - -<H3><A NAME="msie4.0b2">Requests use HTTP/1.1 but responses must be -in HTTP/1.0</A></H3> - -<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 <EM>chunked</EM> 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="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch" ->patch</A> against 1.2.1. - -<H3><A NAME="257th-byte">Boundary problems with header parsing</A></H3> - -<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 -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. - -<H3><A NAME="boundary-string">Multipart responses and Quoted Boundary -Strings</A></H3> - -<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. - -<H3><A NAME="byterange-requests">Byterange requests</A></H3> - -<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. - -<H3><A NAME="cookie-merge"><CODE>Set-Cookie</CODE> header is -unmergeable</A></H3> - -<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. - -<H3><A NAME="gif89-expires"><CODE>Expires</CODE> headers and GIF89A -animations</A></H3> - -<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>. - -<H3><A NAME="no-content-length"><CODE>POST</CODE> without -<CODE>Content-Length</CODE></A></H3> - -<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. - -<H3><A NAME="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3> - -<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>See also Bug-ID's 4124329 and 4125538 at the java developer connection. - -<P>If you are seeing this bug yourself, you can add the following BrowserMatch -directive to work around it: - -<BLOCKQUOTE><CODE> -BrowserMatch "Java1\.2beta[23]" nokeepalive -</CODE></BLOCKQUOTE> - -<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. - -<H3><A NAME="content-type-persistence"><CODE>Content-Type</CODE> change -is not noticed after reload</A></H3> - -<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. - -<h3><a name="msie-cookie-y2k">MSIE Cookie problem with expiry date in -the year 2000</a></h3> - -<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. - -<h3><a name="lynx-negotiate-trans">Lynx incorrectly asking for transparent -content negotiation</a></h3> - -<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. - -<h3><a name="ie40-vary">MSIE 4.0 mishandles Vary response header</a></h3> - -<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> -<PRE> - BrowserMatch "MSIE 4\.0" force-no-vary -</PRE> -<P> -(This workaround is only available with releases <STRONG>after</STRONG> -1.3.6 of the Apache Web server.) -</P> - - -<!--#include virtual="footer.html" --> -</BODY> -</HTML> - |