Re: Apache mod_proxy vs Squid...

It is a HTTP/1.1 100 Continue reply, and any server (or proxy)
sending this in response to a HTTP/1.0 request is in my view broken.
The RFC is a little bit ambigous on this however.. (see below).

A guess on what happens is that the Apache proxy claims to be
HTTP/1.1 when forwarding the request to IIS but forgets to downgrade
the reply to HTTP/1.0 in response to HTTP/1.0 queries from the clent.

IIS usually gets these things right..

In HTTP/1.X the minor version is determined hop-by-hop, where each
hop is responsible for sending queries at the level supported by the
proxy and to downgrade replies to the level supported by the
requestor.

Some relevant annotated quotes from HTTP/1.1:

3.1 HTTP Version

   Proxy and gateway applications need to be careful when forwarding
   messages in protocol versions different from that of the
application.
   Since the protocol version indicates the protocol capability of the
   sender, a proxy/gateway MUST NOT send a message with a version
   indicator which is greater than its actual version. If a higher
   version request is received, the proxy/gateway MUST either
downgrade
   the request version, or respond with an error, or switch to tunnel
   behavior.

   Due to interoperability problems with HTTP/1.0 proxies discovered
   since the publication of RFC 2068[33], caching proxies MUST,
gateways
   MAY, and tunnels MUST NOT upgrade the request to the highest
version
   they support. The proxy/gateway's response to that request MUST be
in
   the same major version as the request.

      Note: Converting between versions of HTTP may involve
modification
      of header fields required or forbidden by the versions involved.

8.2.3 Use of the 100 (Continue) Status

   Requirements for HTTP/1.1 proxies:

      - A proxy MUST NOT forward a 100 (Continue) response if the
        request message was received from an HTTP/1.0 (or earlier)
        client and did not include an Expect request-header field with
        the "100-continue" expectation. This requirement overrides the
        general rule for forwarding of 1xx responses (see section
10.1).

It should be noted that the Expect part above if read as allowing the
use of 100 in HTTP/1.0 if expected is partially in conflict with
caching HTTP/1.0 proxies as HTTP/1.0 proxies do not know about Expect
and will forward it, but cannot be expected to be able to fully deal
with HTTP/1.1 100 replies.

10.1 Informational 1xx

   This class of status code indicates a provisional response,
   consisting only of the Status-Line and optional headers, and is
   terminated by an empty line. There are no required headers for this
   class of status code. Since HTTP/1.0 did not define any 1xx status
   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
   except under experimental conditions.

If the problem is the Expect header, then you should be able to work
around the issue by anonymising away Expect. Unfortunately you first
need to teach Squid that there is a header called Expect..

Regards
Henrik

On Tuesday 02 April 2002 09:41, David Luyer wrote:
> Is this a valid HTTP response? Squid doesn't seem to like it, but
> Apache mod_proxy generates it... (Apache mod_proxy with IIS
> backend), the person doing it is getting an incomplete download of
> pages being served this way:
> --------------------------------
> HTTP/1.1 100 Continue
> Date: Tue, 02 Apr 2002 05:54:31 GMT
> Server: Microsoft-IIS/5.0
> X-Cache: MISS from my.hostname.com
> Connection: close
> Content-Type: text/plain
>
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/5.0
> Date: Tue, 02 Apr 2002 05:54:32 GMT
> Connection: close
> pragma: no-cache
> cache-control: private
> Content-Length: 2296
> Content-Type: text/html
> Expires: Mon, 01 Apr 2002 05:54:32 GMT
> Set-Cookie: ASPSESSIONIDQQQGQJAG=FANJLJGAMJOBGEBCCBFLJFBF; path=/
> Cache-control: no-cache
> --------------------------------
> The problem only happens on POST requests with a certain version of
> Apache... probably an Apache bug.
>
> David.
Received on Tue Apr 02 2002 - 01:58:18 MST