W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: User defined SETTINGS frame extensions

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 7 Feb 2014 12:36:30 -0800
Message-ID: <CAA4WUYhRSKuDbEfKAndnreAmHNm9U7fU1W3dQf54A9vNLOEVBA@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC