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

I wish that POST actually meant "here is something that changes state" and
GET meant "nope,  of changing any state", but both are lies today as far as
I can tell.

POST generally means : here is  form input or here is a file, which
sometimes changes state and sometimes doesn't.

I believe this failure to be the result of not exposing rich enough (and
fully HTTP) semantics to the browser JavaScript and thus having forced the
web application writers to make do with what they had.

I believe at this point that we should probably amend the spec to state the
common practice as a warning to anyone who makes assumptions about
idempotency.

Bleh.

-=R
On Jul 20, 2012 9:26 AM, "James M Snell" <jasnell@gmail.com> wrote:

>
>
> 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
>>
>>
>>
>