server::conn::http1::Connection always holds a proto #3018
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the recent work to split the
server::conn::Http
into protocol-specific halves, the author of that change left the innerproto
in anOption
(and left a comment asking if this was needed any more). This used to be needed as part of the fallback processing (allowing the fallback totake()
the HTTP/1proto
and break it intoParts
in order to rebuild the HTTP/2proto
).Now, since we're definitely using HTTP/1 we can just store the
proto
directly and, in the process delete a bunch ofunwrap
calls 💯. We need to be able totake
the HTTP/1Connection
in a few places (when anUpgradeableConnection
is upgraded for example) but we can scope down the places where we have tounwrap
anOption
that's almost alwaysSome
.I also tidied up a few instances of dead code (some are feature-specific) which I ran into when running
cargo test
over this change.