Re: Some general SPDY feedback / questions

------ Original Message ------
From: "James M Snell" <jasnell@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>
Sent: 8/08/2012 12:33:05 p.m.
Subject: Re: Some general SPDY feedback / questions
>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 ;-) 
yeah sorry :)

It's not deployed, but it works great.  We patched Chromium for it, 
user experience on AV scanning at gateway is a zillion times better 
than what we had before.

anyway.

>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.
how would you currently distinguish the 0 vs 1 vs N 1xx response 
anyway?   I think you'll need to look anyway.
>
>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. 
yeah, late headers.  They give me a really bad feeling.

It gets really nasty any time anyone wants to enforce any sort of 
policy based on header content.  Can late duplicates override previous 
values etc etc.

I know that 1.1 has trailers with chunking (although I thought these 
were being deprecated).

There has to be some sane limit as to what sort of headers you can send 
any time.  For example sending Content-Type any place other than before 
the start of data is a train-wreck waiting to happen.

Intermediaries commonly pass payload via filter chains based on content 
type in order to avoid spooling.  If you had to wait until the transfer 
was complete before filtering, there would be quite an impact on 
perceived performance at the client.

Personally I'd avoid late headers like the plague, or severely restrict 
their use to only certain headers (I can't think of any I'd allow).


Adrien
>
>- 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> 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/
> >  
> >  
> >  
> >  
> >  
 >  
>