- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 10 Oct 2017 01:19:58 +1300
- To: ietf-http-wg@w3.org
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