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

Re: Getting to Consensus on 1xx Status Codes (#535)

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Tue, 22 Jul 2014 01:16:37 -0500
Message-ID: <CACuKZqGXxf-NDiyw-KWQnfMBQx5C743mzi324Bfpg=s7NjfdFA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 21, 2014 at 11:03 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
> On 22 July 2014 13:36, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>>
>> What is the end-to-end semantics though? As far as the application is
>> concerned, the request-response cycle has the same semantics whether
>> or not 100-continue is exchanged under the hood.
>
>
> The semantic that the client application is seeking is confirmation from the
> origin server that it has inspected the headers and has consented for the
> body to be sent.

This is a new way of interpreting it, but it's probably not the
original intent, and it's not supported by the text of the spec. If a
server does not respond with 100, it doesn't mean the body is
forbidden to be sent; the client can always send the body regardless
of server response(s).

> Having an intermediary fake that consent does not
> implement the same semantic, rather it elides the semantic with an assumed
> positive response.
>
>> Whether or not the
>> server can process the request without knowing the body does not rely
>> on the presence of 100-continue, and is not an interesting information
>> that has to be revealed, except for the purpose of optimization.
>
>
> Firstly even if 100 is only an optimisation, we have gone to great lengths
> with h2 to features that provide good quality of service for browser
> clients.  So I do not think we can just remove something which has been long
> implemented to address similar QoS concerns for non browser clients on the
> basis that it is only an optimisation.

Agreed.

>
> Besides, it is not purely an optimisation as it may be that on inspection of
> the headers, the origin server determines that the request content needs to
> be confidential and redirects the client to a secure port.  I'm not saying
> this is a good or common way of implementing security, just that is is a
> use-case I have been asked about about when we did not support 100
> continues.
>
> regards
>
>
>
>
>
>
> --
> 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, 22 July 2014 06:17:04 UTC

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