Add a new constructor and an accessor to Upgrade#105
Add a new constructor and an accessor to Upgrade#105fasterthanlime wants to merge 2 commits intohyperium:masterfrom
Upgrade#105Conversation
Upgrading to HTTP/2.0 is common enough that I feel it should get its own constructor. Because the client can send values other than "websocket" as a request header, I feel like having a getter for the inner value is important.
seanmonstar
left a comment
seanmonstar
left a comment
There was a problem hiding this comment.
Upgrading to HTTP/2.0 is common enough that I feel it should get its own
constructor.
The mechanism using an HTTP header is quite rare, now. All browsers stopped using it, as there are too many servers in the wild that freak out when they see an Upgrade header they don't understand. It's mostly a dead feature now. The world either users ALPN, or just "prior knowledge".
src/common/upgrade.rs
Outdated
| pub fn http2() -> Upgrade { | ||
| // must be uppercase, see | ||
| // <https://datatracker.ietf.org/doc/html/rfc7230#section-2.6> | ||
| Upgrade(HeaderValue::from_static("HTTP/2.0")) |
There was a problem hiding this comment.
But I'm not sure we need this, it's not really used.
There was a problem hiding this comment.
Understood - I added an h2c constructor for that case and noted that ALPN/prior knowledge are overwhelmingly more common for the "http/2 over TLS" case.
src/common/upgrade.rs
Outdated
| /// Returns the header value, e.g. "websocket" or "HTTP/2.0", or a | ||
| /// comma-separated list of protocols, see RFC 7230: | ||
| /// <https://datatracker.ietf.org/doc/html/rfc7230#section-6.7> | ||
| pub fn value(&self) -> &HeaderValue { |
There was a problem hiding this comment.
Some of the typed headers don't hold onto a HeaderValue internally, we might change it here too. So I wouldn't want to return a reference to that type specifically...
There was a problem hiding this comment.
Got it. For now I changed it to return an Option<&str> instead.
2 participants
Upgrading to HTTP/2.0 is common enough that I feel it should get its own
constructor.
Because the client can send values other than "websocket" as a request
header, I feel like having a getter for the inner value is important.