Re: Some general SPDY feedback / questions

On 08.08.2012 03:43, Mark Nottingham wrote:
> On 19/07/2012, at 1:37 AM, James M Snell wrote:
>
>>
>> On Jul 18, 2012 2:35 PM, "Roberto Peon" 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).

The interop problems seem to center around the timeout continuance 
required for 1.0 hops. If the semantics were able to be changed to drop 
connection instead of timeout Expect would have a much better behaviour 
profile.

>
> 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 think its useful to keep for a narrow set of use-cases. Because 
Expect: provides the user/client with the power to mandate particular 
features. It will not be useful on the bulk of traffic as far as I can 
see, but for the paranoid it is actively useful.


IMO, the framing structures proposed for 2.0 is essentially mandatory 
chunking. So the chunked encoding detection use-case is not relevant 
over 2.0 hops. 1.1<->2.0 gateways can essentially be mandatory chunked 
support, and always respond 100-continue when it knows the rest of the 
path is 1.1 or higher (1.1 proxies can do that already today really).

Multi-legged auth on POST etc at a 2.0->1.1 gateway is still a 
bandwidth sucking point. 2.0 semantics for aborting a particular request 
should help optimize things there, particularly of the client end of the 
chain is all 2.0.


I vote for keeping Expect, and 100-continue semantics for secure 
client-driven negotiations. But deprecating the timeout possibility in 
favour of abort and making it clear that chunking negotiation is not 
relevant over 2.0 hops.


Amos

Received on Tuesday, 7 August 2012 23:18:18 UTC