RE: Some general SPDY feedback / questions

This is not correct. Using the 100 continue model explicitly calls out separating on the header/body boundary. There is absolutely no reason for the client to use chunking. The use of 100 was introduced explicitly to deal with PUT and POST in situation where there is potentially a large RTT and it is exposed in common Web client APIs (one case is the .NET HTTP client APIS).

Henrik

-----Original Message-----
From: Adrien W. de Croy [mailto:adrien@qbik.com] 
Sent: Tuesday, August 07, 2012 3:08 PM
To: Henrik Frystyk Nielsen; Mark Nottingham; James M Snell
Cc: Roberto Peon; ietf-http-wg@w3.org
Subject: Re: Some general SPDY feedback / questions


------ Original Message ------
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and robust manner. It allows the client to send the headers which the server can then use to determine whether it can accept the data and as a result give a go-ahead to the client. You don't want the client to start sending a lot of body data if it has to redo the request.
>
we had a discussion about this a couple years back, and it was resolved 
that the only way that 100-continue can provide for the ability to 
retain the client connection is if the client sends chunked request 
bodies, and aborts the transfer of the entity by sending a 0 chunk.

I'm not aware of any client that actually does this.

so AFAICT, 100 continue is unnecessary, and in the end just results in 
extra transmissions for pretty much no visible benefit.

If OTOH it allowed the client to decide not to send the body (e.g. to 
auth instead), it could have been useful.

This came up when I did my original proposal for status updates, in 
relation to multi-legged authentication when dealing with large request 
bodies.

Adrien




>
>
>You can approximate this behavior with careful use of flow-control credits but it will inherently be much cruder because there is no way to separate cleanly on a header/body boundary. As a result it will likely result in wasted bytes transmitted -- something we want to avoid with HTTP/2.0.
>
>Expect on the other hand is in general a failed experiment in my opinion -- you can't retrofit such semantics into an existing protocol.
>
>Henrik
>
>-----Original Message-----
>From: Mark Nottingham [mailto:mnot@mnot.net]
>Sent: Tuesday, August 07, 2012 08:44
>To: James M Snell
>Cc: Roberto Peon; ietf-http-wg@w3.org
>Subject: Re: Some general SPDY feedback / questions
>
>
>On 19/07/2012, at 1:37 AM, James M Snell <jasnell@gmail.com> wrote:
>
>
>>
>>
>>On Jul 18, 2012 2:35 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
>>>[snip]
>>>> 3. How are Informational 1xx Status Codes handled? The current SPDY draft does not appear to support "provisional responses".
>>>
>>>
>>
>>Thank you for the reference to the thread. After reading through it one thing became obvious: while it would likely not be difficult to provide support for a 100-continue like mechanism within spdy, the protocols current design would essentially require a suboptimal hack in order to retain existing http/1.1 semantics and preserve spdy-to-http1.1 pass through or would require that we design a new similar mechanism, optimized for spdy that changes an aspect of http/1.1 semantics.
>>
>>As Mark  has pointed out recently, however, our job here currently is to only define a new transport for http and not to change existing http semantics. So i am at a bit of a loss as to what the charter will let us do in this case.
>>
>>Mark... any guidance?
>>
>
>
>It's a good question. I know that it has come up often on the SPDY list (sometimes raised by me ;).
>
>I'd characterise expect/continue as being on the lighter borders of a grey area; it is used, but it does cause interop problems.  HTTPbis hasn't decided to deprecate it, so it does form part of the semantics of HTTP (unlike, for example, chunk extensions, which we have deprecated).
>
>However, that doesn't preclude us from deciding to not support it in HTTP/2, *if* we can get a good consensus around doing so. I'd be inclined to have a somewhat higher bar for doing so, however.
>
>I'd be interested to hear comments from others, of course.
>
>Cheers,
>
>--
>Mark Nottingham
>http://www.mnot.net/

>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Tuesday, 7 August 2012 22:21:31 UTC