mirror of
https://github.com/apache/httpd.git
synced 2025-10-21 12:13:46 +03:00
d78c998c6a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96194 13f79535-47bb-0310-9956-ffa450edef68
347 lines
15 KiB
HTML
347 lines
15 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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.</p>
|
|
|
|
<h3><a id="trailing-crlf" 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.</p>
|
|
|
|
<h3><a id="broken-keepalive" 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:</p>
|
|
|
|
<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/httpd/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:</p>
|
|
|
|
<blockquote>
|
|
<code>BrowserMatch "MSIE 4\.0b2;" nokeepalive</code>
|
|
</blockquote>
|
|
|
|
<h3><a id="force-response-1.0"
|
|
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:</p>
|
|
|
|
<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>
|
|
|
|
<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:</p>
|
|
|
|
<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:</p>
|
|
|
|
<blockquote>
|
|
<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="byte-257" name="byte-257">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>
|
|
|