known_client_problems.html revision 651f20140031cb01c1fa15b6feb7b98b12330f1c
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips BGCOLOR="#FFFFFF"
5430f7f2bc7330f3088b894166bf3524a067e3d8Lennart Poettering TEXT="#000000"
5430f7f2bc7330f3088b894166bf3524a067e3d8Lennart Poettering LINK="#0000FF"
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips VLINK="#000080"
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips ALINK="#FF0000"
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips<!--#include virtual="header.html" -->
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips<H1 ALIGN="CENTER">Known Problems in Clients</H1>
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philips<P>Over time the Apache Group has discovered or been notified of problems
5430f7f2bc7330f3088b894166bf3524a067e3d8Lennart Poetteringwith various clients which we have had to work around, or explain.
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon PhilipsThis document describes these problems and the workarounds available.
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon PhilipsIt's not arranged in any particular order. Some familiarity with the
4149f86d816fc0fef41d35de5beb09bfe81e0d6aBrandon Philipsstandards is assumed, but not necessary.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>For brevity, <EM>Navigator</EM> will refer to Netscape's Navigator
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekproduct (which in later versions was renamed "Communicator" and
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekvarious other names), and <EM>MSIE</EM> will refer to Microsoft's
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekInternet Explorer product. All trademarks and copyrights belong to
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmektheir respective companies. We welcome input from the various client
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekauthors to correct inconsistencies in this paper, or to provide us with
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekexact version numbers where things are broken/fixed.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>For reference,
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<A HREF="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</A>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<A HREF="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</A>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekdefines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1 server (with an
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Various of these workarounds are triggered by environment variables.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekThe admin typically controls which are set, and for which clients, by using
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<A HREF="/mod/mod_browser.html">mod_browser</A>. Unless otherwise
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmeknoted all of these workarounds exist in versions 1.2 and later.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="trailing-crlf">Trailing CRLF on POSTs</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>This is a legacy issue. The CERN webserver required <CODE>POST</CODE>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekdata to have an extra <CODE>CRLF</CODE> following it. Thus many
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekclients send an extra <CODE>CRLF</CODE> that
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis not included in the <CODE>Content-Length</CODE> of the request.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekApache works around this problem by eating any empty lines which
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekappear before a request.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="broken-keepalive">Broken keepalive</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Various clients have had broken implementations of <EM>keepalive</EM>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek(persistent connections). In particular the Windows versions of
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekNavigator 2.0 get very confused when the server times out an
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekidle connection. The workaround is present in the default config files:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch Mozilla/2 nokeepalive
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekNote that this matches some earlier versions of MSIE, which began the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekpractice of calling themselves <EM>Mozilla</EM> in their user-agent
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekstrings just like Navigator.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>MSIE 4.0b2, which claims to support HTTP/1.1, does not properly
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmeksupport keepalive when it is used on 301 or 302 (redirect)
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekresponses. Unfortunately Apache's <CODE>nokeepalive</CODE> code
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekprior to 1.2.2 would not work with HTTP/1.1 clients. You must apply
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHREF="http://www.apache.org/dist/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek>this patch</A> to version 1.2.1. Then add this to your config:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch "MSIE 4\.0b2;" nokeepalive
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="force-response-1.0">Incorrect interpretation of
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>HTTP/1.1</CODE> in response</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>To quote from section 3.1 of RFC1945:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHTTP uses a "<MAJOR>.<MINOR>" numbering scheme to indicate versions
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekof the protocol. The protocol versioning policy is intended to allow
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekthe sender to indicate the format of a message and its capacity for
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekunderstanding further HTTP communication, rather than the features
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekobtained via that communication.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekSince Apache is an HTTP/1.1 server, it indicates so as part of its
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekresponse. Many client authors mistakenly treat this part of the response
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekas an indication of the protocol that the response is in, and then refuse
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekto accept the response.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>The first major indication of this problem was with AOL's proxy servers.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekWhen Apache 1.2 went into beta it was the first wide-spread HTTP/1.1
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekserver. After some discussion, AOL fixed their proxies. In
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekanticipation of similar problems, the <CODE>force-response-1.0</CODE>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekenvironment variable was added to Apache. When present Apache will
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekindicate "HTTP/1.0" in response to an HTTP/1.0 client,
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekbut will not in any other way change the response.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>The pre-1.1 Java Development Kit (JDK) that is used in many clients
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek(including Navigator 3.x and MSIE 3.x) exhibits this problem. As do some
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekof the early pre-releases of the 1.1 JDK. We think it is fixed in the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek1.1 JDK release. In any event the workaround:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch Java/1.0 force-response-1.0 <BR>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch JDK/1.0 force-response-1.0
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>RealPlayer 4.0 from Progressive Networks also exhibits this problem.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHowever they have fixed it in version 4.01 of the player, but version
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek4.01 uses the same <CODE>User-Agent</CODE> as version 4.0. The
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekworkaround is still:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch "RealPlayer 4.0" force-response-1.0
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="msie4.0b2">Requests use HTTP/1.1 but responses must be
657cf7f4f8d376e082db48022d2be193ff647d06daurnimator<P>MSIE 4.0b2 has this problem. Its Java VM makes requests in HTTP/1.1
657cf7f4f8d376e082db48022d2be193ff647d06daurnimatorformat but the responses must be in HTTP/1.0 format (in particular, it
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekdoes not understand <EM>chunked</EM> responses). The workaround
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis to fool Apache into believing the request came in HTTP/1.0 format.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekThis workaround is available in 1.2.2, and in a
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHREF="http://www.apache.org/dist/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek>patch</A> against 1.2.1.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="257th-byte">Boundary problems with header parsing</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poetteringhave a problem if the trailing CRLF of the response header starts at
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekoffset 256, 257 or 258 of the response. A BrowserMatch for this would
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekmatch on nearly every hit, so the workaround is enabled automatically
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekon all responses. The workaround implemented detects when this condition would
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekoccur in a response and adds extra padding to the header to push the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmektrailing CRLF past offset 258 of the response.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="boundary-string">Multipart responses and Quoted Boundary
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>On multipart responses some clients will not accept quotes (")
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekaround the boundary string. The MIME standard recommends that
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmeksuch quotes be used. But the clients were probably written based
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekon one of the examples in RFC2068, which does not include quotes.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekApache does not include quotes on its boundary strings to workaround
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poettering<H3><A NAME="byterange-requests">Byterange requests</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>A byterange request is used when the client wishes to retrieve a
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekportion of an object, not necessarily the entire object. There
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekwas a very old draft which included these byteranges in the URL.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekOld clients such as Navigator 2.0b1 and MSIE 3.0 for the MAC
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekexhibit this behaviour, and
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekit will appear in the servers' access logs as (failed) attempts to
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekretrieve a URL with a trailing ";xxx-yyy". Apache does not attempt
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekto implement this at all.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>A subsequent draft of this standard defines a header
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Request-Range</CODE>, and a response type
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>multipart/x-byteranges</CODE>. The HTTP/1.1 standard includes
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekthis draft with a few fixes, and it defines the header
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Range</CODE> and type <CODE>multipart/byteranges</CODE>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Navigator (versions 2 and 3) sends both <CODE>Range</CODE> and
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Request-Range</CODE> headers (with the same value), but does not
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekaccept a <CODE>multipart/byteranges</CODE> response. The response must
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekbe <CODE>multipart/x-byteranges</CODE>. As a workaround, if Apache
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekreceives a <CODE>Request-Range</CODE> header it considers it "higher
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekpriority" than a <CODE>Range</CODE> header and in response uses
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>multipart/x-byteranges</CODE>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>The Adobe Acrobat Reader plugin makes extensive use of byteranges and
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekprior to version 3.01 supports only the <CODE>multipart/x-byterange</CODE>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekresponse. Unfortunately there is no clue that it is the plugin
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekmaking the request. If the plugin is used with Navigator, the above
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekworkaround works fine. But if the plugin is used with MSIE 3 (on
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekWindows) the workaround won't work because MSIE 3 doesn't give the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Range-Request</CODE> clue that Navigator does. To workaround this,
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekApache special cases "MSIE 3" in the <CODE>User-Agent</CODE> and serves
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>multipart/x-byteranges</CODE>. Note that the necessity for this
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekwith MSIE 3 is actually due to the Acrobat plugin, not due to the browser.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Netscape Communicator appears to not issue the non-standard
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Request-Range</CODE> header. When an Acrobat plugin prior to
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekversion 3.01 is used with it, it will not properly understand byteranges.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekThe user must upgrade their Acrobat reader to 3.01.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="cookie-merge"><CODE>Set-Cookie</CODE> header is
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>The HTTP specifications say that it is legal to merge headers with
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekduplicate names into one (separated by commas). Some browsers
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekthat support Cookies don't like merged headers and prefer that each
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Set-Cookie</CODE> header is sent separately. When parsing the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekheaders returned by a CGI, Apache will explicitly avoid merging any
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="gif89-expires"><CODE>Expires</CODE> headers and GIF89A
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Navigator versions 2 through 4 will erroneously re-request
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekGIF89A animations on each loop of the animation if the first
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekresponse included an <CODE>Expires</CODE> header. This happens
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekregardless of how far in the future the expiry time is set. There
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis no workaround supplied with Apache, however there are hacks for <A
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHREF="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch">1.2</A>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekHREF="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">1.3</A>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="no-content-length"><CODE>POST</CODE> without
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<CODE>Content-Length</CODE></A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>In certain situations Navigator 3.01 through 3.03 appear to incorrectly
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekissue a POST without the request body. There is no
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekknown workaround. It has been fixed in Navigator 3.04, Netscapes
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<A HREF="http://help.netscape.com/kb/client/971014-42.html">information</A>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<A HREF="http://www.arctic.org/~dgaudet/apache/no-content-length/">
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmeksome information</A> about the actual problem.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>The http client in the JDK1.2beta2 and beta3 will throw away the first part of
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poetteringthe response body when both the headers and the first part of the body are sent
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekin the same network packet AND keep-alive's are being used. If either condition
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis not met then it works fine.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>See also Bug-ID's 4124329 and 4125538 at the java developer connection.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>If you are seeing this bug yourself, you can add the following BrowserMatch
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekdirective to work around it:
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekBrowserMatch "Java1\.2beta[23]" nokeepalive
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>We don't advocate this though since bending over backwards for beta software
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis usually not a good idea; ideally it gets fixed, new betas or a final release
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekcomes out, and no one uses the broken old software anymore. In theory.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<H3><A NAME="content-type-persistence"><CODE>Content-Type</CODE> change
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekis not noticed after reload</A></H3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<P>Navigator (all versions?) will cache the <CODE>content-type</CODE>
50d9e46dbb8400d4570781728c63b151d9ca982bZbigniew Jędrzejewski-Szmekfor an object "forever". Using reload or shift-reload will not cause
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekNavigator to notice a <CODE>content-type</CODE> change. The only
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekwork-around is for the user to flush their caches (memory and disk). By
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekway of an example, some folks may be using an old <CODE>mime.types</CODE>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekfile which does not map <CODE>.htm</CODE> to <CODE>text/html</CODE>,
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekin this case Apache will default to sending <CODE>text/plain</CODE>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekIf the user requests the page and it is served as <CODE>text/plain</CODE>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekAfter the admin fixes the server, the user will have to flush their caches
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekbefore the object will be shown with the correct <CODE>text/html</CODE>
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poettering<h3><a name="msie-cookie-y2k">MSIE Cookie problem with expiry date in
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<p>MSIE versions 3.00 and 3.02 (without the Y2K patch) do not handle
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekcookie expiry dates in the year 2000 properly. Years after 2000 and
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekbefore 2000 work fine. This is fixed in IE4.01 service pack 1, and in
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekthe Y2K patch for IE3.02. Users should avoid using expiry dates in the
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<h3><a name="lynx-negotiate-trans">Lynx incorrectly asking for transparent
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<p>The Lynx browser versions 2.7 and 2.8 send a "negotiate: trans" header
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekin their requests, which is an indication the browser supports transparent
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekcontent negotiation (TCN). However the browser does not support TCN.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekAs of version 1.3.4, Apache supports TCN, and this causes problems with
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poetteringthese versions of Lynx. As a workaround future versions of Apache will
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekignore this header when sent by the Lynx client.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<h3><a name="ie40-vary">MSIE 4.0 mishandles Vary response header</a></h3>
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmek<p>MSIE 4.0 does not handle a Vary header properly. The Vary header is
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekgenerated by mod_rewrite in apache 1.3. The result is an error from MSIE
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmeksaying it cannot download the requested file. There are more details
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-Szmekin <a href="http://bugs.apache.org/index/full/4118">PR#4118</a>.
302fbdf29eb0ad4ca1fe8ee18755edad7db11b37Zbigniew Jędrzejewski-SzmekA workaround is to add the following to your server's configuration
b705ab6a838937f947216af7b2d1fffb00f8b0dcZbigniew Jędrzejewski-Szmek BrowserMatch "MSIE 4\.0" force-no-vary
6a9171d2ec4f2cc1d7850fcb7b076cb75fbd3dd3Lennart Poettering(This workaround is only available with releases <STRONG>after</STRONG>
b705ab6a838937f947216af7b2d1fffb00f8b0dcZbigniew Jędrzejewski-Szmek1.3.6 of the Apache Web server.)
b705ab6a838937f947216af7b2d1fffb00f8b0dcZbigniew Jędrzejewski-Szmek<!--#include virtual="footer.html" -->