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

#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/
>
>
>
>
>
>