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

Re: h2 header field names

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 4 Sep 2014 11:26:46 +0300
Cc: Martin Thomson <martin.thomson@gmail.com>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <843A253B-27A6-474A-B0DD-55DE2D8CA988@mnot.net>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
I was responding to your question about the “architectural decision” of a character set.


On 4 Sep 2014, at 11:21 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> In message <1AB5985B-A9F8-40BE-B4D7-70EC84FBF4E8@mnot.net>, Mark Nottingham wri
> tes:
> 
>>> There is a valid architectual question: are headers ASCII or UTF-8?
>>> 
>>> But the lack of decision on that doesn't mean that we have to
>>> let through BEL, BS and ESC while we make up our mind.
>>> 
>>> And why don't we just make the architectural decision in the
>>> first place ?
>> 
>> The time for doing that was in 2616bis. We talked about it a lot, and 
>> decided we couldn't retroactively change the allowed values - and 
>> that doing so might not be a good idea anyway.
> 
> ...and that's water under the bridge now.
> 
> And if this had been HTTP/1.2 I would also agree that all HTTP/1.1
> traffic must be able to pass through.
> 
> But we're doing HTTP/2.0.
> 
> The general interpretation of a new major version number bump in
> the IT industry is "You'd better read the manual to see what's
> changed".
> 
> People will be expecting some things not to work, and they'll expect
> the changes to be for the better.
> 
> Firming up things like charset for headers would therefore make
> people think more and better of HTTP/2.0 than if we just grandfather
> all the HTTP/1.1 warts in and add new ones.
> 
> 
> What actual trouble do you expect to see if we firm up the definition
> of header character sets in HTTP/2.0 ?
> 
> HTTP/1 through HTTP/2 tunneling is going to be mostly between a
> proxy/balancer and web-severes, and if that doesn't work because
> the web-service emits NUL in headers, they'll figure out and
> postpone HTTP/2 deployment until they fix their pointer-errors.
> 
> I also don't understand the arbitrainess of these decisions.
> 
> We have jettisoned retaining HTTP/1.1 chunking when tunneling through
> HTTP/2.0, but we have to retain their NUL characters in headers ?
> 
> Far more applications rely on chunk-boundaries than on NUL headers,
> so what exactly is our compatibility criteria here ?
> 
> 
> I really don't get it...
> 
> 
> -- 
> 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.

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 4 September 2014 08:27:16 UTC

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