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