From ad71dd9ec1ea65db9eb6ac2ded0e72a3f6e4f903 Mon Sep 17 00:00:00 2001 From: dgaudet Date: Sun, 20 Jul 1997 21:26:47 +0000 Subject: [PATCH] First draft of all the problems we know about and have worked around... git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@78701 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/misc/known_client_problems.html | 188 ++++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 docs/manual/misc/known_client_problems.html diff --git a/docs/manual/misc/known_client_problems.html b/docs/manual/misc/known_client_problems.html new file mode 100644 index 0000000000..0dde9c2944 --- /dev/null +++ b/docs/manual/misc/known_client_problems.html @@ -0,0 +1,188 @@ + + + +Apache HTTP Server Project + + + + + +

Known Problems in Clients

+ +

Over time the Apache Group has discovered or been notified of problems +with various clients which we have had to work around. 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. + +

For brevity, Navigator will refer to Netscape's Navigator +product, and MSIE 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. + +

For reference, +RFC1945 +defines HTTP/1.0, and +RFC2068 +defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1 server (with an +optional HTTP/1.0 proxy). + +

Various of these workarounds are triggered by environment variables. +The admin typically controls which are set, and for which clients, by using +mod_browser. Unless otherwise +noted all of these workarounds exist in versions 1.2 and later. + +

Trailing CRLF on POSTs

+ +

This is a legacy issue. The CERN webserver required POST +data to have an extra CRLF following it. Thus many +clients send an extra CRLF that +is not included in the Content-Length of the request. +Apache works around this problem by eating any empty lines which +appear before a request. + +

Broken keepalive

+ +

Various clients have had broken implementations of keepalive +(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: +

+BrowserMatch Mozilla/2 nokeepalive +

+Note that this matches some earlier versions of MSIE, which began the +practice of calling themselves Mozilla in their user-agent +strings just like Navigator. + +

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 nokeepalive code +prior to 1.2.2 would not work with HTTP/1.1 clients. You must apply +this +patch to version 1.2.1. Then add this to your config: +

+BrowserMatch "MSIE 4\.0b2;" nokeepalive +

+ +

Incorrect interpretation of `HTTP/1.1` in response

+ +

To quote from section 3.1 of RFC1945: +

+HTTP uses a "." 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. +

+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. + +

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 force-response-1.0 +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. + +

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: +

+BrowserMatch Java1.0 force-response-1.0 +BrowserMatch JDK/1.0 force-response-1.0 +

+ +

RealPlayer 4.0 from Progressive Networks also exhibits this problem: +

+BrowserMatch "RealPlayer 4.0" force-response-1.0 +

+ +

Requests use HTTP/1.1 but responses must be in HTTP/1.0

+ +

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 chunked responses). The workaround +is to fool Apache into believing the request came in HTTP/1.0 format. +

+BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0 +

+This workaround is available in 1.2.2, and in a +patch + against 1.2.1. + +

Boundary problems with header parsing

+ +

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 +the 256th or 257th byte of the response. A BrowserMatch for this would +match on nearly every hit, so the workaround is enabled automatically +on all responses. The workaround is to detect when this condition would +occur in a response and add extra padding to the header to push the +trailing CRLF past the 257th byte of the response. + +

Multipart responses and Quoted Boundary Strings

+ +

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. + +

Byterange requests

+ +

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. + +

A subsequent draft of this standard defines a header +Request-Range, and a response type +multipart/x-byteranges. The HTTP/1.1 standard includes +this draft with a few fixes, and it defines the header +Range and type multipart/byteranges. + +

Navigator (versions 2 and 3) sends both Range and +Request-Range headers (with the same value), but does not +accept a multipart/byteranges response. The response must +be multipart/x-byteranges. As a workaround, if Apache +receives a Request-Range header it considers it "higher +priority" than a Range header and in response uses +multipart/x-byteranges. + +

The Adobe Acrobat Reader plugin makes extensive use of byteranges and +prior to version 3.01 supports only the multipart/x-byterange +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 +Range-Request clue that Navigator does. To workaround this, +Apache special cases "MSIE 3" in the User-Agent and serves +multipart/x-byteranges. Note that the necessity for this +with MSIE 3 is actually due to the Acrobat plugin, not due to the browser. + +

Netscape Communicator appears to not issue the non-standard +Request-Range 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. + + + + + -- 2.50.1