Re: HTTP2: Header Field Name.

On 03/10/17 20:12, Felix wrote:
> Hi.
> I was writing a h2 server lately.
> I'm failed to find a good reason from rfc7540 or rfc7541 to necessarily convert header field name to lowercase.
> 
> There are some disadvantages for a h2-to-h1 proxy about it:
> 1. Before forward a header stream to h1 endpoint. It may need to compare every header name. If the name is an iana registered name, convert it to upper camel-case. For example, convert "content-type" to "Content-Type". Apparently, this is not very efficient.

This is wrong. As Daniel said already HTTP/1 header names are case 
insensitive. So the h2 name is what the proxy should output.

If your proxy has a registry of HTTP/1 names it should make some minimal 
effort to produce the defacto standard casing, but is not required to.


> 2. User could add a custom header entry with a name "MyParameter" to headers. If sender's sdk return error about it, that just make people think http2 is a step backward compare to http. If sender's sdk converts the name to lowercase then send it. The h1 receiver will not get "MyParameter" value, cause it's named "myparameter" now.
> 
> If we remove the lowercase rule. There is an advantage:
> I don't know why header names are dash-line connected nowadays.

They are because they are. The dash is a character the author(s) 
defining a header get to choose from just like the numbers and alphabet 
characters. Some choose to use it, some dont.

> But if we will add some new feature with a new header to http2. We can use upper camel-case name. Compare CoolFeature to Cool-Feature, that's one byte saved.

Only in the human-readable format.

HTTP/2 is binary protocol. Having case sensitivity increases the machine 
versions size through increased static/dynamic table entry counts, 
increases the risk of permutation attacks, and adds lots of small 
incidental issues with case management have to be avoided for it all to 
work right.

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

Consider it this way:

"CoolFeature" and "COOlfEAtUrE" are the same name in HTTP (both 1.x and 
2). As are all other possible permutations of upper and lower case 
characters.

Now how does the HPACK encoder encode all possible case *insensitive* 
permutations use "the one true name" when it is case-sensitive and has 
no list of all future defined headers casing?

Also, the lower casing is not new in HTTP/2. It exists implicitly in 
HTTP/1 as well through the case-insensitive definition. HTTP/2 makes 
naive agents simpler as the case sensitivity no longer has to be 
accounted for and provides a nice big stick to get bad implementations 
fixed when converting to h2.


> 
> If we remove the lowercase rule. We need remove rules described in section 8.1.2, 8.1.2.6 in rfc7540. Turn Static Table Entries back to upper camel-case in rfc7541.
> 
> This change will affect all http2 implementations. It's not too late since http2 is not widely used yet.
> 

On the contrary; As Daniel said, HTTP/2 is already widely used and 
growing quite fast.

Amos

Received on Monday, 9 October 2017 12:20:33 UTC