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

On 2 Jul 2014, at 12:48 pm, David Krauss <potswa@gmail.com> wrote:

> 
> On 2014–07–02, at 10:24 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> 
>> On 2 Jul 2014, at 12:21 pm, David Krauss <potswa@gmail.com> wrote:
>> 
>>> That gives applications a tough choice.
>>> 
>>> Perhaps the corresponding non-pseudo header should always be a fallback, implemented at the API level, if the pseudo header is absent?
>>> 
>>> I’m not clear on what appeal pseudo headers currently have at all, except to a punctuation fetish.
>> 
>> Pseudo headers shouldn't be available to the application, full stop; they're just a mechanism to get what was special-case syntax in HTTP/1 into general header syntax in /2. 
> 
> The application is required (or at least, asked nicely) to fill them. And they can be freely read at the other end. The restriction is on defining new ones.

Yes; read my statement as "Pseudo headers *not defined by the ALPN token* shouldn't..."


> 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. 


>> They contain a colon specifically because it's illegal in field names, so that they're clearly different. Making them extensible is IMO inviting them to be exposed by APIs as headers or similar, and that's a land of rich bugs and security problems.
>> 
> Different how? A field name with a colon is also a field name. It’s not an HTTP/1.1 field name, but I must be missing something here.

The range of HTTP header field names is not magically changed by HTTP/2; it's still as defined in RFC7231 <http://tools.ietf.org/html/rfc7230#section-3.2>.

> 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.
"""

> I’m not suggesting extensibility. My initial reply to this thread was the strictest so far, that pseudo headers should only be added where deemed necessary by HTTP itself. This only really makes sense with additional, new restrictions such as that they should be encoded first in a header set representation. But without restrictions the colon just seems like a new color of bike shed paint.



--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 2 July 2014 04:38:11 UTC