Re: User defined SETTINGS frame extensions

http://http2.github.io/http2-spec/#SettingValues says: "An endpoint
that receives a SETTINGS frame with any other setting identifier MUST
treat this as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR."

People discussed allowing this sort of extensibility at the Zurich
interim. I think it was fairly contentious but overall we decided to
disallow it. You're absolutely right that this kind of extensibility
could have value, but I think we killed it off like we killed off all
other extensibility, since people should just use a different ALPN
token. I don't think there was a strong consensus at all, so you
should push on this if you have strong feelings here.

On Fri, Feb 7, 2014 at 12:23 PM, Daniel Sommermann <dcsommer@fb.com> wrote:
> Right now, the HTTP/2 spec reserves higher numbers SETTINGS identifiers for
> future revisions to the protocol. Would there be a benefit to allowing users
> to register/reserve identifiers for their own use? Or perhaps a weaker, more
> practical version of this: set aside a range of high numbered identifiers
> (ala ephemeral ports) that are reserved for internal use within controlled
> networks. It could be useful to allow two internal HTTP/2 endpoints to
> exchange information via SETTINGS that do not make sense for the internet at
> large.
>

Received on Friday, 7 February 2014 20:36:57 UTC