W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #535: No 1xx Status Codes

From: Greg Wilkins <gregw@intalio.com>
Date: Tue, 15 Jul 2014 23:30:10 +1000
Message-ID: <CAH_y2NF064bYAykNyR0Dq-kbWZZkqRhGLpxFG+shgmE6hvz7iw@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC