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

Re: Some general SPDY feedback / questions

From: Adrien W. de Croy <adrien@qbik.com>
Date: Tue, 07 Aug 2012 23:26:51 +0000
To: "James M Snell" <jasnell@gmail.com>, "Mike Belshe" <mike@belshe.com>
Cc: "Mark Nottingham" <mnot@mnot.net>, "Roberto Peon" <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em0e78faca-18bb-4fde-8c4a-83b3ddc652a5@bombed>

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

>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> 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/
Received on Tuesday, 7 August 2012 23:27:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC