W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Some general SPDY feedback / questions

From: James M Snell <jasnell@gmail.com>
Date: Tue, 7 Aug 2012 17:33:05 -0700
Message-ID: <CABP7RbfCLNhEMpVFSVwnrJs8cyB+57TXnU9z0cskoGue_vCeAw@mail.gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Mike Belshe <mike@belshe.com>, Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "James M Snell" <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.

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.

- James


>  Adrien
>
>   4. The non 1xx :status header MUST be sent before any DATA frames are
> sent in the response.
>
> With that, an application can be assured that they'll have the final
> actual status code before processing any of the response data.
>
> - James
>
>
> On Tue, Aug 7, 2012 at 4:08 PM, Mike Belshe < <mike@belshe.com>
> mike@belshe.com> wrote:
>
>>
>> [snip]
>>  Making SPDY (or HTTP/2.) suport it, however, is relatively simple.
>>  James' proposal in this thread is getting close.  I'm a little worried
>> about demarcation of the two sets of headers, but the rest is
>> straightforward.
>>
>> Mike
>>
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham
>>> <http://www.mnot.net/>http://www.mnot.net/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Received on Wednesday, 8 August 2012 00:33:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 August 2012 00:34:04 GMT