- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Wed, 25 Aug 2010 02:03:49 +0200
- To: ietf-http-wg@w3.org
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
Received on Wednesday, 25 August 2010 00:04:25 UTC