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

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.

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.

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

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.

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.

Received on Wednesday, 2 July 2014 02:49:18 UTC