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

Re: h2 header field names

From: Kinkie <gkinkie@gmail.com>
Date: Thu, 4 Sep 2014 19:22:27 +0200
Message-ID: <CA+Y8hcNpEwQr5A1d=TyBuwTetqWevo=-OSvvMMRCRqhgvCp-dQ@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Jason Greene <jason.greene@redhat.com>, Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org, Amos Jeffries <squid3@treenet.co.nz>
On Sep 4, 2014 7:11 PM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
>
> --------
> In message <54088BD2.1030100@gmx.de>, Julian Reschke writes:
>
> >The main reason why I'm concerned about arbitrary binary data is that
> >all of the HTTP APIs I'm aware essentially work on character sequences,
> >not octet sequences (in header fields).
>
> That is my concern too:  Most code handling HTTP today don't expect
> to see embedded NUL's, and a lot of it will happily send through
> "poison" characters like ESC.
>
> >The lack of a standard encoding in HTTP/1.1 is already a problem;
>
> But we could apply gentle persuasion here:  If we make HPACK work
> really well with baser64 (it does, but could be better) a lot of
> people will take the hint.  Not everybody, but a lot of them.

You are an optimist, aren't you?
People will happily choose whatever is easiest to implement and works,
especially in enterprise "intranet" environments.

So either allowed character sets are made very strict, or it's just as well
that it is not considered it a protocol issue,  and is better managed at
the application framework level,  where the protocol should stay as much as
possible out of the way. I'm convinced halfway measures will not achieve
anything worthy.
Received on Thursday, 4 September 2014 17:22:54 UTC

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