Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

On Fri, Jul 20, 2012 at 12:52 AM, Willy Tarreau <w@1wt.eu> wrote:
> [snip]
> > >
> > > POST /public HTTP/1.1
> > > Host: www.example.com
> > > Expect: 100-Continue
> > > Content-Length: 100
> > >
> > > GET /private HTTP/1.1
> > > Host: www.example.com
> >
> > In the above example the use of content-length requires that the server
> > drain 100 bytes regardless of what the client does.
>
> [snip]
So this would be yet another argument in favor of spdy-style framing and
multiplexing
Consider, for instance,
Client Server
 | |
 |======================>|
 | 1) SYN_STREAM |
 | id=1 |
 | method=POST |
 | expect=100 |
 | content-length:100 |
 | |
 |======================>|
 | 2) SYN_STREAM |
 | id=3 |
 | method=GET |
 | |
Due to the multiplexed framing model, the client can proceed with Stream #3
without waiting for the server to respond to the POST and without worrying
about whether the server will drop the data on the floor due to the
content-length header. If the server takes too long to respond to Stream
#1, it can attempt to go ahead and send the Stream #1 Data frames or it can
abandon the stream with a RST_STREAM without requiring the connection to be
killed off.
That said, fwiw, HTTP/1.1 clients are not supposed to be pipelining
non-idempotent methods anyway, so sending a GET on the same connection as a
POST, especially one that is using Expect: 100 is simply bad form.
- James
> Regards,
> Willy
>
>
>