Re: #536: clarify extensibility for :pseudo header fields

On 2014–07–02, at 12:37 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 
> On 2 Jul 2014, at 12:48 pm, David Krauss <potswa@gmail.com> wrote:
> 
>> ALPN based specs will need to decide whether to sacrifice compatibility with HTTP/1.1 proxies. Where the sacrifice is made, we’ll still see applications choosing to forgo pseudo headers and omit the colon, effectively defining a new non-pseudo. That’s the tough choice
> 
> It's a lot more than that; if they're trying to map into HTTP semantics, they'll have to figure out how to represent the headers in existing APIs. 

Simply strip the colon. I suspect that even when the ALPN spec mentions nothing of the sort, it will be a practical workaround anyway. It’s obvious enough to warrant a specific prohibition, if you want folks not to do this.

Graceful degradation dictates that the subset of HTTP/2 usage surviving translation through HTTP/1.1 should be maximized.

I think we’re basically viewing the situation through different glasses: you’re supposing people will use the protocol as intended, and I’m supposing that people will use whatever workarounds maximize compatibility. Call it devil’s advocate.

>> Nothing in the current spec suggests they shouldn’t be accessible as headers or similar. Without some indication to the contrary, APIs will expose them simply by default, and the damage will be done.
> 
> <http://http2.github.io/http2-spec/#HttpHeaders>:
> 
> """
> Header field names that start with a colon are only valid in the HTTP/2 context. These are not HTTP header fields. Implementations MUST NOT generate header fields that start with a colon, and they MUST ignore and discard any header field that starts with a colon. In particular, header fields with names starting with a colon MUST NOT be exposed as HTTP header fields.
> “""

OK, thanks, I stand corrected. This is the rule that we are currently adjusting, and my suggestion was only the status quo.

Still, even such a prohibition against exposing as header fields doesn’t prevent “something similar.” Are general HTTP/2 APIs really going to force users to wait for support for each ALPN token, or will they allow for early adoption and customization by exposing the pseudos?

This territory sounds like it will be difficult to legislate, because competitive pressures will push the other way.