RE: User defined SETTINGS frame extensions

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