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

On 1 July 2014 13:29, Mark Nottingham <> wrote:

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

Received on Tuesday, 1 July 2014 04:34:22 UTC