headers could be symbols?

[ioquatix]

Is it possible that we can apply #to_s to header keys? This allows us to use symbols rather than strings.

[igrigorik]

In theory, I think that's fine.. It should be a no-op if it's already a string value (minus the extra class check). The relevant code is: https://github.com/igrigorik/http-2/blob/master/lib/http/2/compressor.rb#L205

[ioquatix]

It's pretty much a no-op both for symbols and strings.

I'm still working through how I want this to work though. It might end up better just to use strings.

Perhaps you have a moment to listen to my situation.

I'm implementing async-http as you know which is a client and server for both http1 and http2, and it tries to have an invariant API for both protocols.

One thing I've been wresting with is what exactly should a header look like.

We have some general answer with HTTP2 - there is a normal form - a lower case string, e.g. content-length. Therefore, should we normalise all HTTP1 headers to fit this? Then, user code can just work like headers['content-length']. Other alternatives include the more obscure headers["HTTP_CONTENT_LENGTH"] which requires manipulation of header key both on the way in (reading request) and the way out (making request).

Another option with ruby is to convert all headers to symbol keys, either as :'content-length' or :content_length. I don't like normalising to use underscore since that might clobber headers and also requires transformation similar to using HTTP_ prefix.

So, the options are, normalise keys to be lower case strings, for both HTTP1/2 or do the same but convert to symbol, but the syntax is a bit less pleasant. Using symbols has a large performance advantage but only at the micro-benchmark level. Ruby has some improvements to string keys too, which minimise the effect in some cases.

Thoughts?

[igrigorik]

We have some general answer with HTTP2 - there is a normal form - a lower case string, e.g. content-length. Therefore, should we normalise all HTTP1 headers to fit this?

Per spec, HTTP header names are case-insensitive, +1 for this approach.

• :"field-name" doesn't win you much in ergonomics or readability
• last option of headers[HTTP_CONTENT_LENGTH] works with above too if you want to use constants for lowercased values instead of minting new string objects each time.

[HoneyryderChuck]

I think this is a non issue, that has been solved a long time ago, even in net-http, and I used the same approach in httpx.

• define your internal representation as lowercase, format the user input according to this.
• symbols don't give you any advantage. Hifen doesn't map well to it.

I also think that such concerns belong to a wrapper lib, and a parser lib should not concern itself with such details. And the way it currently works is just fine.

[ioquatix]

Users often try to use symbols or non-normalised strings for header keys.

Also there is some issue with older browsers which apparently did have case-sensitive headers. It might be a "non-issue" in theory, but in practice there are some problems.

[HoneyryderChuck]

I don't think that users will provide symbols, unless your API states support. As for the non-normalized header fields, that's what I meant with "solved problem".

I suggest you to see how httpx or net-http solve this, specifically the Header class implementation and what is done with user input.

If you roll your eyes on the possible amount of string objects created, you'll have to come with a better way of compromising user code compatibility while sacrificing gc performance :) .