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

On 1 July 2014 13:29, Mark Nottingham <mnot@mnot.net> wrote:

> <https://github.com/http2/http2-spec/issues/536>
>
> It looks like the options so far are:
>
> 1) Define a registry for :headers
>
> 2) Make the list of acceptable :headers static with respect to the ALPN
> token
>
> Thoughts? Other options?
>
>
​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)

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?

So I suspect option 2 is the better choice.​​


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/