Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

headers could be symbols? #124

Closed
ioquatix opened this issue Apr 5, 2018 · 6 comments
Closed

headers could be symbols? #124

ioquatix opened this issue Apr 5, 2018 · 6 comments

Comments

@ioquatix
Copy link
Collaborator

ioquatix commented Apr 5, 2018

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

@igrigorik
Copy link
Owner

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
Copy link
Collaborator Author

ioquatix commented Apr 6, 2018

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
Copy link
Owner

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
Copy link
Collaborator

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
Copy link
Collaborator Author

ioquatix commented Apr 8, 2018

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
Copy link
Collaborator

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

@ioquatix ioquatix closed this as completed Apr 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants