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.

Adrien



------ Original Message ------
From: "James M Snell" <jasnell@gmail.com>
To: "Mike Belshe" <mike@belshe.com>
Cc: "Amos Jeffries" <squid3@treenet.co.nz>;"ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
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" <mike@belshe.com> wrote:
>>
>>
>[Snip]
>>
>>
>> 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 
>received.
>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
>>>
>>