Re: Some general SPDY feedback / questions

do we even envisage sending entity headers on 1xx responses?

I don't know if it's a good idea.

in which case, we'd only get entity headers on the final response 
before the data.


------ Original Message ------
From: "James M Snell" <>
To: "Mike Belshe" <>
Cc: "Amos Jeffries" <>;"" 
Sent: 10/08/2012 10:54:37 a.m.
Subject: Re: Some general SPDY feedback / questions
>On Aug 9, 2012 2:26 PM, "Mike Belshe" <> wrote:
>> 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?
>There is a definite trade off in complexity, that's for sure... but if 
>we need to support 1xx responses I don't see another way to do it 
>without increasing the complexity even further.
>Headers would essentially be single value, if a subsequent headers 
>frame repeats a previously seen header, the value for that header is 
>replaced. If the application has already processed that header, the 
>application needs to figure out how to handle the situation. 
>>    - when can a receiver know when headers are 'done'?  If you sent 
>one set of cache-related headers, can you send further ones later?
>The headers are done once the first data frame is sent or the FIN is 
>For cache headers, it would be important to note that repeated headers 
>would replace the existing value, not add to the value, so subsequent 
>cache control headers would supersede any that came before. 
>> 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".
>Understood, and the reasoning is sound, but there really doesn't 
>appear to be another simpler way of supporting provisional responses. 
>There is an increased burden on the developer to handle repeated 
>headers properly but I doubt that burden is much more than what 
>developers are already accustomed to. 
>- James
>> Mike
>>> Amos

Received on Friday, 10 August 2012 00:09:29 UTC