- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 18 Jul 2012 10:48:21 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I don't think the spec is broken on 100-continue. However, as a practical matter, how many servers *really* support the mechanism? As far as I know, all major Java implementations immediately send back a "HTTP/1.1 100 Continue\r\n\r\n" response if the request carries header "Expect: 100-continue". Therefore they support the feature on paper, yet completely defeat its purpose. Zhong Yu On Tue, Jul 17, 2012 at 3:31 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2012-07-17 21:45, Osama Mazahir wrote: >> >> As it is currently, 100-continue is problematic. The situation is tricky >> because the client is not forced to wait for the 100/417/4xx (i.e. client is >> allowed to timeout and send the entity body). Thus, the server does not >> have a deterministic way to now if the next byte after the double CRLF is >> the first byte of the next request or the first byte of the entity body (of >> the initial request). This results in connections getting closed in various >> edge/error cases. >> >> 100-continue is almost there but if we wanted to use it in a robust manner >> in HTTP2 then I think we would have to revisit its specification. >> ... > > > Well, we are revising RFC 2616, and if something is broken here we should > consider to fix it. Or, minimally, document the problem. > > If I understand correctly, this will happen if the client sends "Expect: > 100-continue", the server is slow to return an error status, and the client > decides to give up waiting for the 100 status, and continues? > > Best regards, Julian > > >
Received on Wednesday, 18 July 2012 15:48:47 UTC