Re: HTTP2: Header Field Name.

On Tue, Oct 03, 2017 at 07:12:33AM +0000, Felix wrote:
> But if we will add some new feature with a new header to http2. We can use
> upper camel-case name.

What an horror! CamelCase was invented only to make editors add
auto-completion. Every time you use an acronym (ie: almost always in
network environments), you never know how the words have to be spelled.
People love to write "TransmissionControlProtocol", then later shorten
it to "TCP" when it's mixed with some other words ("NewTCP") but then
when considered as TCP and not a shortened form as the above, it becomes
"Tcp" so you'll have "TcpClose" and such stuff. I've yet to see code
where camel case remains consistent for acronyms!

> Compare CoolFeature to Cool-Feature, that's one byte saved.

That's wrong, because in HTTP "Cool-Feature" is the same as "cool-feature"
so you save one bit per character = 12 bits total by having the dash instead
of upper cases, compared to the former where each character must have a bit
to indicate the case. As long as you have on average less than one dash per
8 caracters, the dash wins. This counts when you start to use certain
compression algorithms such as Huffman.

> If we only allows lowercase, the dash-line is required. Without
> dash-line, it's not readable.

That's why there's the dash. In HTTP header field names, just like for file
names, config keywords, composed first names, the dash is used to associate
words together to form a larger non-breakable word.

Another thing to consider is that going case-sensitive in a text-oriented
protocol supporting intermediaries creates security issues, because you can
do whatever you want, you'll always find implementations not properly checking
the case for such a widely deployed protocol. These ones can be attacked by
bypassing the intermediaries. And it has already been the case 15 years ago
where some load balancers could not properly parse "content-length:" or
"cookie:". So better make this the norm (and save bits on the wire).

> This change will affect all http2 implementations. It's not too late since
> http2 is not widely used yet.

No, for sure, it's just compatible with HTTP/1.0 and 1.1 which have been
around since 1996 or so, so probably not that many implementations will
notice if you change it after 21 years of unimaginable use cases :-)

Willy

Received on Monday, 9 October 2017 19:44:42 UTC