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 13:58:33 -0800
Message-ID: <CAA4WUYi12LbOO_6o9X-x09LKOhkOi-nGuwWXKqWmQZcDL7YhZQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>
That recollection of the discussion sounds right to me. FWIW, here's
what the minutes

Issue 95 Extensibility

Hum was 50-50.

Decided against. Unhandled SETTINGS MUST be ignored, though.

On Fri, Feb 7, 2014 at 1:56 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> The general outcome of that discussion was that, if you want to add custom setting values or frame types to the base spec, you should define a corresponding ALPN string (e.g. "H2-FB") so you can be sure both parties know about and agree to use the extra values.  It's a higher bar and encourages fragmentation (which I don't like), but it gets rid of the need to negotiate what's supported or to restrict what those settings can do.
> -----Original Message-----
> From: willchan@google.com [mailto:willchan@google.com] On Behalf Of William Chan (???)
> Sent: Friday, February 7, 2014 12:37 PM
> To: Daniel Sommermann
> Cc: HTTP Working Group
> Subject: 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 21:59:01 UTC

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