known_client_problems.html revision 2eaf662cbc81e823e8d9aeb8d54e69e63032493e
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi<html xmlns="http://www.w3.org/1999/xhtml">
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <head>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <meta name="generator" content="HTML Tidy, see www.w3.org" />
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <title>Apache HTTP Server Project</title>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi </head>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi vlink="#000080" alink="#FF0000">
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <!--#include virtual="header.html" -->
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <h1 align="CENTER">Known Problems in Clients</h1>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>Over time the Apache Group has discovered or been notified
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi of problems with various clients which we have had to work
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi around, or explain. This document describes these problems and
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi the workarounds available. It's not arranged in any particular
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi order. Some familiarity with the standards is assumed, but not
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi necessary.</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>For brevity, <em>Navigator</em> will refer to Netscape's
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi Navigator product (which in later versions was renamed
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi "Communicator" and various other names), and <em>MSIE</em> will
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi refer to Microsoft's Internet Explorer product. All trademarks
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi and copyrights belong to their respective companies. We welcome
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi input from the various client authors to correct
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi inconsistencies in this paper, or to provide us with exact
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi version numbers where things are broken/fixed.</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>For reference, <a
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi href="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</a>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi defines HTTP/1.0, and <a
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi href="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</a>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi server (with an optional HTTP/1.0 proxy).</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>Various of these workarounds are triggered by environment
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi variables. The admin typically controls which are set, and for
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi which clients, by using <a
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi href="/mod/mod_browser.html">mod_browser</a>. Unless
a23343e9e4e0b555b1bcfa99a7455e0e28117a3dJean-Noel Rouvignac otherwise noted all of these workarounds exist in versions 1.2
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi and later.</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <h3><a id="trailing-crlf" name="trailing-crlf">Trailing CRLF on
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi POSTs</a></h3>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>This is a legacy issue. The CERN webserver required
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>POST</code> data to have an extra <code>CRLF</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi following it. Thus many clients send an extra <code>CRLF</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi that is not included in the <code>Content-Length</code> of the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi request. Apache works around this problem by eating any empty
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi lines which appear before a request.</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <h3><a id="broken-keepalive" name="broken-keepalive">Broken
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi keepalive</a></h3>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>Various clients have had broken implementations of
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <em>keepalive</em> (persistent connections). In particular the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi Windows versions of Navigator 2.0 get very confused when the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi server times out an idle connection. The workaround is present
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi in the default config files:</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>BrowserMatch Mozilla/2 nokeepalive</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi </blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi Note that this matches some earlier versions of MSIE, which
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi began the practice of calling themselves <em>Mozilla</em> in
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi their user-agent strings just like Navigator.
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>MSIE 4.0b2, which claims to support HTTP/1.1, does not
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi properly support keepalive when it is used on 301 or 302
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi (redirect) responses. Unfortunately Apache's
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>nokeepalive</code> code prior to 1.2.2 would not work
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi with HTTP/1.1 clients. You must apply <a
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi href="http://www.apache.org/dist/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi this patch</a> to version 1.2.1. Then add this to your
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi config:</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>BrowserMatch "MSIE 4\.0b2;" nokeepalive</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi </blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <h3><a id="force-response-1.0"
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi name="force-response-1.0">Incorrect interpretation of
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>HTTP/1.1</code> in response</a></h3>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>To quote from section 3.1 of RFC1945:</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi HTTP uses a "&lt;MAJOR&gt;.&lt;MINOR&gt;" numbering scheme to
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi indicate versions of the protocol. The protocol versioning
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi policy is intended to allow the sender to indicate the format
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi of a message and its capacity for understanding further HTTP
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi communication, rather than the features obtained via that
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi communication.
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi </blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi Since Apache is an HTTP/1.1 server, it indicates so as part of
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi its response. Many client authors mistakenly treat this part of
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi the response as an indication of the protocol that the response
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi is in, and then refuse to accept the response.
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>The first major indication of this problem was with AOL's
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi proxy servers. When Apache 1.2 went into beta it was the first
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi wide-spread HTTP/1.1 server. After some discussion, AOL fixed
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi their proxies. In anticipation of similar problems, the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>force-response-1.0</code> environment variable was added
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi to Apache. When present Apache will indicate "HTTP/1.0" in
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi response to an HTTP/1.0 client, but will not in any other way
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi change the response.</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>The pre-1.1 Java Development Kit (JDK) that is used in many
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi clients (including Navigator 3.x and MSIE 3.x) exhibits this
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi problem. As do some of the early pre-releases of the 1.1 JDK.
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi We think it is fixed in the 1.1 JDK release. In any event the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi workaround:</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>BrowserMatch Java/1.0 force-response-1.0<br />
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi BrowserMatch JDK/1.0 force-response-1.0</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi </blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <p>RealPlayer 4.0 from Progressive Networks also exhibits this
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi problem. However they have fixed it in version 4.01 of the
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi player, but version 4.01 uses the same <code>User-Agent</code>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi as version 4.0. The workaround is still:</p>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <blockquote>
8b806159078ce1308b27e676c0e8a6340f05e6e0Fabio Pistolesi <code>BrowserMatch "RealPlayer 4.0" force-response-1.0</code>
</blockquote>
<h3><a id="msie4.0b2" 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.</p>
<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/httpd/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">
patch</a> against 1.2.1.
<h3><a id="257th-byte" 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.</p>
<h3><a id="boundary-string" 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.</p>
<h3><a id="byterange-requests"
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>
<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>
<h3><a id="cookie-merge"
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.</p>
<h3><a id="gif89-expires"
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>.</p>
<h3><a id="no-content-length"
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.</p>
<h3><a id="jdk-12-bugs" 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>
<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>
<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.</p>
<h3><a id="content-type-persistence"
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.</p>
<h3><a id="msie-cookie-y2k" 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.</p>
<h3><a id="lynx-negotiate-trans"
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.</p>
<h3><a id="ie40-vary" 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>