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

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

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.