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

RE: User defined SETTINGS frame extensions

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Fri, 7 Feb 2014 21:56:18 +0000
To: William Chan (Dz) <willchan@chromium.org>, "Daniel Sommermann" <dcsommer@fb.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <b64d526883ce4237996d12e77ec89b64@BY2PR03MB091.namprd03.prod.outlook.com>
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:56:48 UTC

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