- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 16 Mar 2004 06:40:51 +0000
- To: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP WG <ietf-http-wg@w3.org>
Jeffrey Mogul wrote: > Also, as I understand the paper, what they showed is that while > if everyone fully (and correctly) implemented the 100-Continue > specification of RFC2616, everything would be fine, we didn't > successfully design this feature to interoperate with RFC2068. > We also apparently said "MAY" instead of "MUST" in at least one > place, so partial (but legal) implementations of RFC2616 might > be a problem. Thank you! It is a most excellent paper. The conclusion for someone writing an RFC2616 server is that "MAY send a 100 [...] in response to an HTTP/1.1 PUT or POST request" must be implemented as "MUST, after a timeout, ..." (or with no timeout), to avoid certain deadlocks. Other conclusions apply for someone writing a proxy or client. Neither Apache 1 nor 2 actually do that, so I presume the theoretical deadlock isn't a problem in practice. Probably because the few clients which do wait for 100 (Continue), if there are any at all, implement a reasonably short timeout before sending the request entity anyway, even though that's prohibited by RFC2068. How wonderfully unclear. - Jamie
Received on Tuesday, 16 March 2004 01:41:00 UTC