Re: h2 header field names

--------
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.

Received on Thursday, 4 September 2014 08:22:08 UTC