- From: Greg Wilkins <gregw@intalio.com>
- Date: Tue, 15 Jul 2014 23:30:10 +1000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NF064bYAykNyR0Dq-kbWZZkqRhGLpxFG+shgmE6hvz7iw@mail.gmail.com>
On 15 July 2014 19:18, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > But isn't it already supported via the per-stream windows ? > > It's true that the sender can fill the initial per stream window > before the receiver has a chance to decide if it wants the body > or not, but I've never seen the 100-Continue as a mechanism to > avoid sending a few unwanted tens of kilobyts, but rather to avoid > sending unwanted mega- and gigabytes ? > The use case I've most often seen it used in is with REST/SOAP clients that want to check that their credentials are correct or if they are talking to the correct server before sending any payload. Here is Amazon S3 talking about it: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTRedirect.html#RESTRedirect100Continue In their use-case up to 64KB of data could be sent that then has to be resent. As such architectures often to many redirects, this could be an issue. Note also that if the client has started sending the request body, then it is going to be harder for it to be stopped and redirected. It may end up serialising a lot more data and then having to do it again. I think there is a tiny bit of a security issue as well, as sometimes a request is redirected to a secure port, so 100 thus prevents the client from sending data over an insecure connection. (I'm not saying it is good security, but I have definitely heard of it being relied on!) Another aspect of this is that many REST/SOAP clients are not browsers, so they will not be able to be upgraded easily. So h1 to h2 proxies are going to have to handle 100 continues correctly if these clients are to work. To well support the semantic, you need the application itself to be able to inspect the request headers and then signal that it either needs the request body or provides an alternate response. So I really think this is a not uncommon http1 semantic that if we drop is against our charter. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Tuesday, 15 July 2014 13:30:41 UTC