Re: FYI... Binary Optimized Header Encoding for SPDY

On Thu, Aug 2, 2012 at 1:27 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <
> CABaLYCv7U7iLBu5+8Nb9Wa1VeQguoMLJw4VOCbDBQK3WoE-sFg@mail.gmail.com>
> , Mike Belshe writes:
>
> >> > * I don't think we need utf-8 encoded headers.  Not sure how you'd
> pass
> >> them off to HTTP anyway?
> >
> >I just don't see any problem being solved by adding this?  If there is no
> >benefit, we should not do it, right?
>
> If this would solve any major problems inside a 20 year horizon, we
> should do it.
>
> That being said, I am not a big fan of UTF8 in high-performance
> protocol context:  It is much slower to process than 8bit string
> formats.
>
>
This is precisely why I favor the introduction of a binary value option and
the definition of highly-optimized binary encodings for the most commonly
used protocol headers (like method, version, etc). Things like Host and
Request URI need to be looked at tho. I suspect that, for a variety of
reason, we'll want to keep limiting those values to ASCII only.  (just
because the value COULD be UTF-8, doesn't mean a specific header definition
cannot limit the actual value to some reasonable subset).


> UTF8 also gives rise to a number of interesting security aspects,
> primarily where humans eyeball for security and don't detect minor
> differences between glyphs, particularly in FQDNs, but I can't see
> how we can do anything about that in HTTP/2.0.
>
> It's not obvious to me, that we can evade the UTF8 requirement,
> so it might be worthwhile to consider what we can gain by embracing
> it.
>
> For instance, could we get rid of the %-encoding of URIs by allowing UTF8 ?
>

It would be possible, for instance, to begin using IRI's directly without
translating those to URI's first. Doing so, however, does not eliminate the
need for %-encoding, and there are a range of possible issues that could
make this problematic.

- James


>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>