Re: Some general SPDY feedback / questions

On Tue, Aug 7, 2012 at 11:12 PM, Amos Jeffries <> 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 <<mailto:
>>>> wrote:
>>     ------ Original Message ------
>>     From: "James M Snell" < <>>
>>>     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)


> Amos

Received on Thursday, 9 August 2012 21:23:19 UTC