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 >> >> >> >
Received on Friday, 20 July 2012 16:42:26 UTC