Comments (6)
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
from http-2.
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 :) .
from http-2.
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?
from http-2.
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.
from http-2.
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.
from http-2.
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.
from http-2.
Related Issues (20)
- Sending RST_STREAM on closed Streams results in GOAWAY HOT 1
- Failing client requests HOT 30
- Connection.activate_stream RuntimeError: can't add a new key into hash during iteration HOT 13
- How does one know when headers are finished? HOT 13
- Is it okay to have multiple `set-cookie` headers? HOT 2
- How to deal with idempotent requests which fail? HOT 9
- goaway when talking to Cloudflare HOT 15
- release 0.9.1 with warning fixes HOT 4
- Gem is not fully compliant with RFC7540 Chapter 8 requirements on request/response headers. HOT 2
- receiving ping while closing connection causing ProtocolError HOT 5
- This repo has no a license. HOT 4
- SETTINGS_HEADER_TABLE_SIZE validation? HOT 1
- Could we add flags to headers/data event? HOT 5
- ignoring frame size negotiation HOT 1
- Heavy CPU usage while trying to cleanup closed streams
- Decompressor comment incorrect HOT 2
- HTTP2::Client.new throws ArgumentError (wrong number of arguments (given 1, expected 0)) on Ruby 3.0 HOT 3
- Connection upgrade fails when request body is not empty HOT 1
- Increasing initial-window beyond 128K results in no window-updates HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from http-2.