Subject: Issue: expect 100-continue in HTTP/1.0 requests

From: Henrik Nordström <[email-masked]>
Date: Wed, 25 Aug 2010 02:03:49 +0200

In another discussion Expect: 100-continue & HTTP/1.0 came up again.

I think the HTTP/1.1 wording regarding this is overly optimistic and is
causing interoperability failures with HTTP/1.0.

The problem arises if there is HTTP/1.0 proxies involved. If those
follow RFC1945 then forwarding of 100 Continue will not work proper as
the HTTP/1.0 proxy do not know there will be additional response
messages following the 1xx message.

RFC1945 even explicitly says (9.1 Informational 1xx)

   HTTP/1.0 does not define any 1xx status
   codes and they are not a valid response to a HTTP/1.0 request.
   However, they may be useful for experimental applications which are
   outside the scope of this specification.

While 2616 (and P1-messaging) says:

      - An origin server SHOULD NOT send a 100 (Continue) response if
        the request message does not include an Expect request-header
        field with the "100-continue" expectation, and MUST NOT send a
        100 (Continue) response if such a request comes from an HTTP/1.0
        (or earlier) client. [...]

and similarly for proxies:

   o  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 8.1 of [Part2]).

which imho is in direct conflict with RFC1945 as this arises naturally
(not experimentally) under the condition

   HTTP/1.1 client -> HTTP/1.0 proxy -> HTTP/1.1 server.

Squid prior to 2.6.STABLE7 (Mar 2007) is an example where this condition
can be triggered, with oddness as result. Note there is still plenty of
Squid-2.5 installs out there.

Many existing server implementations ignore Expect: 100-continue on
HTTP/1.0 responses to improve interoperability, even if strictly in
conflict with RFC2616.

This applies to 1xx in general. Unsafe to use in response to HTTP/1.0
request even if headers suggests it should be used.

Actually, responding with 417 would be the proper response rather than
ignoring the Expect, but that too fails interop testing as many clients
sending Expect: 100-continue fails to fall back on non-expect method
when getting a 417 back..

Regards
Henrik