W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Delta Compression and UTF-8 Header Values

From: James M Snell <jasnell@gmail.com>
Date: Fri, 8 Feb 2013 12:21:50 -0800
Message-ID: <CABP7RbdrKWR-rzKGh9sFXJaqqQojLCQtNknRDfCqER1Ln29FAg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: ietf-http-wg@w3.org
On Feb 8, 2013 11:50 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> I guess the relevant question then is: Are these headers where it
> is necessary for HTTP entities to understand the value (ie:
> "Cache-Control", "Location" etc, ) or headers which are just
> transported transparently from end to end ("X-FOObar", "Cookie"
> etc.)
> In the latter case, supporting UTF-8 is merely a matter of letting
> another bit through per byte, in the former case it opens a major
> bucket of worms IMO.

No argument there. However, this bucket of worms is no worse than several
of the others we've already been considering :)

The key headers where this becomes the most relevant are :host, :path,
Content-Disposition, Link, and possibly Cookie/Set-Cookie (that's a big

If nothing else, it would be helpful to have a single encoding defined for
all non-ascii header field values that can be indicated by a bit flag. E.g.
if the flag is set, value is hex encoded binary. It doesn't alleviate all
the issues, of course, but  does simplify things for app developers.

> --
> 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
Received on Friday, 8 February 2013 20:22:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC