granicus.if.org Git - apache/blob - docs/manual/misc/known_client_problems.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>Apache HTTP Server Project</TITLE>
   5 </HEAD>
   6
   7 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
   8 <BODY
   9  BGCOLOR="#FFFFFF"
  10  TEXT="#000000"
  11  LINK="#0000FF"
  12  VLINK="#000080"
  13  ALINK="#FF0000"
  14 >
  15 <!--#include virtual="header.html" -->
  16 <H1 ALIGN="CENTER">Known Problems in Clients</H1>
  17
  18 <P>Over time the Apache Group has discovered or been notified of problems
  19 with various clients which we have had to work around, or explain.
  20 This document describes these problems and the workarounds available.
  21 It's not arranged in any particular order.  Some familiarity with the
  22 standards is assumed, but not necessary.
  23
  24 <P>For brevity, <EM>Navigator</EM> will refer to Netscape's Navigator
  25 product (which in later versions was renamed "Communicator" and
  26 various other names), and <EM>MSIE</EM> will refer to Microsoft's
  27 Internet Explorer product.  All trademarks and copyrights belong to
  28 their respective companies.  We welcome input from the various client
  29 authors to correct inconsistencies in this paper, or to provide us with
  30 exact version numbers where things are broken/fixed.
  31
  32 <P>For reference,
  33 <A HREF="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</A>
  34 defines HTTP/1.0, and
  35 <A HREF="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</A>
  36 defines HTTP/1.1.  Apache as of version 1.2 is an HTTP/1.1 server (with an
  37 optional HTTP/1.0 proxy).
  38
  39 <P>Various of these workarounds are triggered by environment variables.
  40 The admin typically controls which are set, and for which clients, by using
  41 <A HREF="../mod/mod_browser.html">mod_browser</A>.  Unless otherwise
  42 noted all of these workarounds exist in versions 1.2 and later.
  43
  44 <H3><A NAME="trailing-crlf">Trailing CRLF on POSTs</A></H3>
  45
  46 <P>This is a legacy issue.  The CERN webserver required <CODE>POST</CODE>
  47 data to have an extra <CODE>CRLF</CODE> following it.  Thus many
  48 clients send an extra <CODE>CRLF</CODE> that
  49 is not included in the <CODE>Content-Length</CODE> of the request.
  50 Apache works around this problem by eating any empty lines which
  51 appear before a request.
  52
  53 <H3><A NAME="broken-keepalive">Broken keepalive</A></H3>
  54
  55 <P>Various clients have had broken implementations of <EM>keepalive</EM>
  56 (persistent connections).  In particular the Windows versions of
  57 Navigator 2.0 get very confused when the server times out an
  58 idle connection.  The workaround is present in the default config files:
  59 <BLOCKQUOTE><CODE>
  60 BrowserMatch Mozilla/2 nokeepalive
  61 </CODE></BLOCKQUOTE>
  62 Note that this matches some earlier versions of MSIE, which began the
  63 practice of calling themselves <EM>Mozilla</EM> in their user-agent
  64 strings just like Navigator.
  65
  66 <P>MSIE 4.0b2, which claims to support HTTP/1.1, does not properly
  67 support keepalive when it is used on 301 or 302 (redirect)
  68 responses.  Unfortunately Apache's <CODE>nokeepalive</CODE> code
  69 prior to 1.2.2 would not work with HTTP/1.1 clients.  You must apply
  70 <A
  71 HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
  72 >this patch</A> to version 1.2.1.  Then add this to your config:
  73 <BLOCKQUOTE><CODE>
  74 BrowserMatch "MSIE 4\.0b2;" nokeepalive
  75 </CODE></BLOCKQUOTE>
  76
  77 <H3><A NAME="force-response-1.0">Incorrect interpretation of
  78 <CODE>HTTP/1.1</CODE> in response</A></H3>
  79
  80 <P>To quote from section 3.1 of RFC1945:
  81 <BLOCKQUOTE>
  82 HTTP uses a "&lt;MAJOR&gt;.&lt;MINOR&gt;" numbering scheme to indicate versions
  83 of the protocol. The protocol versioning policy is intended to allow
  84 the sender to indicate the format of a message and its capacity for
  85 understanding further HTTP communication, rather than the features
  86 obtained via that communication.
  87 </BLOCKQUOTE>
  88 Since Apache is an HTTP/1.1 server, it indicates so as part of its
  89 response.  Many client authors mistakenly treat this part of the response
  90 as an indication of the protocol that the response is in, and then refuse
  91 to accept the response.
  92
  93 <P>The first major indication of this problem was with AOL's proxy servers.
  94 When Apache 1.2 went into beta it was the first wide-spread HTTP/1.1
  95 server.  After some discussion, AOL fixed their proxies.  In
  96 anticipation of similar problems, the <CODE>force-response-1.0</CODE>
  97 environment variable was added to Apache.  When present Apache will
  98 indicate "HTTP/1.0" in response to an HTTP/1.0 client,
  99 but will not in any other way change the response.
 100
 101 <P>The pre-1.1 Java Development Kit (JDK) that is used in many clients
 102 (including Navigator 3.x and MSIE 3.x) exhibits this problem.  As do some
 103 of the early pre-releases of the 1.1 JDK.  We think it is fixed in the
 104 1.1 JDK release.  In any event the workaround:
 105 <BLOCKQUOTE><CODE>
 106 BrowserMatch Java/1.0 force-response-1.0 <BR>
 107 BrowserMatch JDK/1.0 force-response-1.0
 108 </CODE></BLOCKQUOTE>
 109
 110 <P>RealPlayer 4.0 from Progressive Networks also exhibits this problem.
 111 However they have fixed it in version 4.01 of the player, but version
 112 4.01 uses the same <CODE>User-Agent</CODE> as version 4.0.  The
 113 workaround is still:
 114 <BLOCKQUOTE><CODE>
 115 BrowserMatch "RealPlayer 4.0" force-response-1.0
 116 </CODE></BLOCKQUOTE>
 117
 118 <H3><A NAME="msie4.0b2">Requests use HTTP/1.1 but responses must be
 119 in HTTP/1.0</A></H3>
 120
 121 <P>MSIE 4.0b2 has this problem.  Its Java VM makes requests in HTTP/1.1
 122 format but the responses must be in HTTP/1.0 format (in particular, it
 123 does not understand <EM>chunked</EM> responses).  The workaround
 124 is to fool Apache into believing the request came in HTTP/1.0 format.
 125 <BLOCKQUOTE><CODE>
 126 BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
 127 </CODE></BLOCKQUOTE>
 128 This workaround is available in 1.2.2, and in a
 129 <A
 130 HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
 131 >patch</A> against 1.2.1.
 132
 133 <H3><A NAME="257th-byte">Boundary problems with header parsing</A></H3>
 134
 135 <P>All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
 136 have a problem if the trailing CRLF of the response header starts at
 137 offset 256, 257 or 258 of the response.  A BrowserMatch for this would
 138 match on nearly every hit, so the workaround is enabled automatically
 139 on all responses.  The workaround implemented detects when this condition would
 140 occur in a response and adds extra padding to the header to push the
 141 trailing CRLF past offset 258 of the response.
 142
 143 <H3><A NAME="boundary-string">Multipart responses and Quoted Boundary
 144 Strings</A></H3>
 145
 146 <P>On multipart responses some clients will not accept quotes (")
 147 around the boundary string.  The MIME standard recommends that
 148 such quotes be used.  But the clients were probably written based
 149 on one of the examples in RFC2068, which does not include quotes.
 150 Apache does not include quotes on its boundary strings to workaround
 151 this problem.
 152
 153 <H3><A NAME="byterange-requests">Byterange requests</A></H3>
 154
 155 <P>A byterange request is used when the client wishes to retrieve a
 156 portion of an object, not necessarily the entire object.  There
 157 was a very old draft which included these byteranges in the URL.
 158 Old clients such as Navigator 2.0b1 and MSIE 3.0 for the MAC
 159 exhibit this behaviour, and
 160 it will appear in the servers' access logs as (failed) attempts to
 161 retrieve a URL with a trailing ";xxx-yyy".  Apache does not attempt
 162 to implement this at all.
 163
 164 <P>A subsequent draft of this standard defines a header
 165 <CODE>Request-Range</CODE>, and a response type
 166 <CODE>multipart/x-byteranges</CODE>.  The HTTP/1.1 standard includes
 167 this draft with a few fixes, and it defines the header
 168 <CODE>Range</CODE> and type <CODE>multipart/byteranges</CODE>.
 169
 170 <P>Navigator (versions 2 and 3) sends both <CODE>Range</CODE> and
 171 <CODE>Request-Range</CODE> headers (with the same value), but does not
 172 accept a <CODE>multipart/byteranges</CODE> response.  The response must
 173 be <CODE>multipart/x-byteranges</CODE>.  As a workaround, if Apache
 174 receives a <CODE>Request-Range</CODE> header it considers it "higher
 175 priority" than a <CODE>Range</CODE> header and in response uses
 176 <CODE>multipart/x-byteranges</CODE>.
 177
 178 <P>The Adobe Acrobat Reader plugin makes extensive use of byteranges and
 179 prior to version 3.01 supports only the <CODE>multipart/x-byterange</CODE>
 180 response.  Unfortunately there is no clue that it is the plugin
 181 making the request.  If the plugin is used with Navigator, the above
 182 workaround works fine.  But if the plugin is used with MSIE 3 (on
 183 Windows) the workaround won't work because MSIE 3 doesn't give the
 184 <CODE>Range-Request</CODE> clue that Navigator does.  To workaround this,
 185 Apache special cases "MSIE 3" in the <CODE>User-Agent</CODE> and serves
 186 <CODE>multipart/x-byteranges</CODE>.  Note that the necessity for this
 187 with MSIE 3 is actually due to the Acrobat plugin, not due to the browser.
 188
 189 <P>Netscape Communicator appears to not issue the non-standard
 190 <CODE>Request-Range</CODE> header.  When an Acrobat plugin prior to
 191 version 3.01 is used with it, it will not properly understand byteranges.
 192 The user must upgrade their Acrobat reader to 3.01.
 193
 194 <H3><A NAME="cookie-merge"><CODE>Set-Cookie</CODE> header is
 195 unmergeable</A></H3>
 196
 197 <P>The HTTP specifications say that it is legal to merge headers with
 198 duplicate names into one (separated by semicolon).  Some browsers
 199 that support Cookies don't like merged headers and prefer that each
 200 <CODE>Set-Cookie</CODE> header is sent separately.  When parsing the
 201 headers returned by a CGI, Apache will explicitly avoid merging any
 202 <CODE>Set-Cookie</CODE> headers.
 203
 204 <H3><A NAME="gif89-expires"><CODE>Expires</CODE> headers and GIF89A
 205 animations</A></H3>
 206
 207 <P>Navigator versions 2 through 4 will erroneously re-request
 208 GIF89A animations on each loop of the animation if the first
 209 response included an <CODE>Expires</CODE> header.  This happens
 210 regardless of how far in the future the expiry time is set.  There
 211 is no workaround supplied with Apache, however there are hacks for <A
 212 HREF="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch">1.2</A>
 213 and for <A
 214 HREF="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">1.3</A>.
 215
 216 <H3><A NAME="no-content-length"><CODE>POST</CODE> without
 217 <CODE>Content-Length</CODE></A></H3>
 218
 219 <P>In certain situations Navigator 3.01 through 3.03 appear to incorrectly
 220 issue a POST without the request body.  There is no
 221 known workaround.  It has been fixed in Navigator 3.04, Netscapes
 222 provides some
 223 <A HREF="http://help.netscape.com/kb/client/971014-42.html">information</A>.
 224 There's also
 225 <A HREF="http://www.arctic.org/~dgaudet/apache/no-content-length/">
 226 some information</A> about the actual problem.
 227
 228 <H3><A NAME="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3>
 229
 230 <P>The http client in the JDK1.2beta2 and beta3 will throw away the first part of
 231 the response body when both the headers and the first part of the body are sent
 232 in the same network packet AND keep-alive's are being used. If either condition
 233 is not met then it works fine.
 234
 235 <P>See also Bug-ID's 4124329 and 4125538 at the java developer connection.
 236
 237 <P>If you are seeing this bug yourself, you can add the following BrowserMatch
 238 directive to work around it:
 239
 240 <BLOCKQUOTE><CODE>
 241 BrowserMatch "Java1\.2beta[23]" nokeepalive
 242 </CODE></BLOCKQUOTE>
 243
 244 <P>We don't advocate this though since bending over backwards for beta software
 245 is usually not a good idea; ideally it gets fixed, new betas or a final release
 246 comes out, and no one uses the broken old software anymore.  In theory.
 247
 248 <H3><A NAME="content-type-persistence"><CODE>Content-Type</CODE> change
 249 is not noticed after reload</A></H3>
 250
 251 <P>Navigator (all versions?) will cache the <CODE>content-type</CODE>
 252 for an object "forever".  Using reload or shift-reload will not cause
 253 Navigator to notice a <CODE>content-type</CODE> change.  The only
 254 work-around is for the user to flush their caches (memory and disk).  By
 255 way of an example, some folks may be using an old <CODE>mime.types</CODE>
 256 file which does not map <CODE>.htm</CODE> to <CODE>text/html</CODE>,
 257 in this case Apache will default to sending <CODE>text/plain</CODE>.
 258 If the user requests the page and it is served as <CODE>text/plain</CODE>.
 259 After the admin fixes the server, the user will have to flush their caches
 260 before the object will be shown with the correct <CODE>text/html</CODE>
 261 type.
 262
 263 <h3><a name="msie-cookie-y2k">MSIE Cookie problem with expiry date in
 264 the year 2000</a></h3>
 265
 266 <p>MSIE versions 3.00 and 3.02 (without the Y2K patch) do not handle
 267 cookie expiry dates in the year 2000 properly.  Years after 2000 and
 268 before 2000 work fine.  This is fixed in IE4.01 service pack 1, and in
 269 the Y2K patch for IE3.02.  Users should avoid using expiry dates in the
 270 year 2000.
 271
 272 <h3><a name="lynx-negotiate-trans">Lynx incorrectly asking for transparent
 273 content negotiation</a></h3>
 274
 275 <p>The Lynx browser versions 2.7 and 2.8 send a "negotiate: trans" header
 276 in their requests, which is an indication the browser supports transparent
 277 content negotiation (TCN).  However the browser does not support TCN.
 278 As of version 1.3.4, Apache supports TCN, and this causes problems with
 279 these versions of Lynx.  As a workaround future versions of Apache will
 280 ignore this header when sent by the Lynx client.
 281
 282 <h3><a name="ie40-vary">MSIE 4.0 mishandles Vary response header</a></h3>
 283
 284 <p>MSIE 4.0 does not handle a Vary header properly.  The Vary header is
 285 generated by mod_rewrite in apache 1.3.  The result is an error from MSIE
 286 saying it cannot download the requested file.  There are more details
 287 in <a href="http://bugs.apache.org/index/full/4118">PR#4118</a>.
 288
 289 <!--#include virtual="footer.html" -->
 290 </BODY>
 291 </HTML>
 292