Re: Some general SPDY feedback / questions

On Tue, Aug 7, 2012 at 11:12 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

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


When you do this, it opens up a new set of things to define:
   - what happens if a header is superseded later? can you send the same
header twice?
   - when can a receiver know when headers are 'done'?  If you sent one set
of cache-related headers, can you send further ones later?

I know these sound like edges, and even the spdy framer sort-of allows
header frames at any time... but at the app layer, it creates a lot of new
questions that http doesn't have today.  this is why in SPDY we just said
"although the framing layer can do it, for HTTP's purposes, you (mostly)
can't".

Mike





>
> Amos
>
>