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

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

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 1 Jul 2014 19:50:10 -0700
Message-ID: <CAP+FsNe4ZjgxN5jWTQNQJ_gXpWPqeZbFMqiDCKfBDOTRTkzGFg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: David Krauss <potswa@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
#2/ hard fail looks good to me here.
imho keys beginning with ':' are reserved for future versions of the
protocol, and should not be treated the same as others.
-=R


On Tue, Jul 1, 2014 at 7:24 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 2 Jul 2014, at 12:21 pm, David Krauss <potswa@gmail.com> wrote:
>
> >
> > On 2014ā€“07ā€“02, at 10:11 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> >>
> >> On 2 Jul 2014, at 3:49 am, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >>
> >>> I'm split between demanding RST_STREAM+PROTOCOL_ERROR or ignoring
> >>> unknown values.  Slight preference for the former though.  I think
> >>> that's consistent with Matthew's proposal.
> >>
> >> +1 for hard fail.
> >
> > 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.
>
> 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.
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>
Received on Wednesday, 2 July 2014 02:50:38 UTC

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