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

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

From: David Krauss <potswa@gmail.com>
Date: Wed, 2 Jul 2014 10:48:37 +0800
Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1E477F03-9F64-40EE-B3C2-83FB7C75C6A1@gmail.com>
To: Mark Nottingham <mnot@mnot.net>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC