Re: Some general SPDY feedback / questions

On 8/08/2012 12:33 p.m., James M Snell wrote:
> On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <adrien@qbik.com 
> <mailto:adrien@qbik.com>> wrote:
>
>
>     ------ Original Message ------
>     From: "James M Snell" <jasnell@gmail.com <mailto:jasnell@gmail.com>>
>>     What exactly is your worry?
>>
>>     My general concern about it deals more with application handling
>>     of the response than with anything else... it would be good to
>>     apply some rules... for instance...
>>
>>     1. An updated :status header MUST ONLY be sent if the initial
>>     SYN_REPLY :status header is a 1xx response code,
>>     2. No more than one 1xx response code can be sent per response,
>     this contravenes 2616 which explicitly states that any number may
>     be sent, and must be handled appropriately.
>>     3. Once a non 1xx :status has been sent, it is a protocol error
>>     to send any additional :status headers,
>     this is a semantic change.   We actually now use multiple 1xx for
>     status updates in the lab.  I don't know if there are other uses,
>     but there are legitimate use-cases for it.
>     If 2.0 can support some other OOB notification mechanism, then all
>     well and good.
>
>
> Aw man.. you had to go and ruin it with Reality... how annoying ;-) I 
> suppose that, at least in theory, we could support multiple 1xx 
> :status headers to be sent so long as the final non-1xx :status is 
> still sent *before* any response DATA frames, but that does get kind 
> of messy and tedious... we'd end up having to check every HEADERS 
> frame for a possible :status header that overrides the previously 
> received one... and that just gets silly.

Take a gander through the network-friendly-00 draft. Notice how the 
response status has a frame type of its own for precisely this use-case. 
The frame type and status value is easily available in the envelope 
octets for this validity check to be done at high speed without having 
to muddle through any of the rest of the frame(s) structure.

>
> The one thing I would note, however, is that HEADERS frames can be 
> sent anytime in the stream making it possible for other kinds of 
> signaling beyond :status to occur. The only restriction being how such 
> additional HEADERS frames affect the HTTP semantics.

+1.

Amos

Received on Wednesday, 8 August 2012 06:12:39 UTC