Re: #536: clarify extensibility for :pseudo header fields

On Tue, 01 Jul 2014 06:33:54 +0200, Matthew Kerwin <matthew@kerwin.net.au>  
wrote:

> ​Ideologically I prefer setting up a registry, since I expect (hope?)  
> that extensions will end up informing HTTP2bis and/or >bootstrapping  
> HTTP3.
>
>> However, I can't think of a use case for a :header that can't equally  
>> be served by an extension frame.  Consider this strawman, >which is the  
>> best proposal I can come up with for safe but extensible :headers:
>
>> ]  An endpoint must raise a PROTOCOL_ERROR if it receives an unknown
> ]  :header. Extensions may define new :headers on the conditions that
> ]  1) support has to be advertised before the header can be sent, and
> ]  2) the receiver has to translate/remove it before forwarding, if the
> ]  downstream peer hasn't advertised support.
>
>> (editorial issues and tone notwithstanding)

I like this. It makes it much easier to tie request specific meta data to  
the correct request than separate extension frames.


>
>> Unless the new :header has widespread support off the bat, it's going  
>> to end up being used hop-by-hop, which -- because of the >resulting  
>> churn in HPACK contexts -- makes it less valuable than an extension  
>> frame.
>
>> A less restrictive proposal (e.g. only forcing the translation/removal  
>> at a 1.1 gateway) provides end-to-end extension >:headers in a pure  
>> HTTP2 environment, but what's the utility of a header that has to be  
>> stripped if it passes a 1.1 leg on its >journey?

Extension frames don't survive 1.1 gateways either, so I don't see this as  
a good argument.

/Martin Nilsson

>
>> So I suspect option 2 is the better choice.​​
>
>
> -- Matthew Kerwin
>  http://matthew.kerwin.net.au/



-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/