1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
|
<!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>
|
