-
Notifications
You must be signed in to change notification settings - Fork 86
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
HTTP/3 connection params #151
Closed
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
468040b
HTTP/3 connection params
eagr e4e207f
don't accept argument with boolean setter
eagr 1aa7e12
Params -> Config
eagr 2320bd4
replace endpoint builders with config builders
eagr a10cfa9
derive Debug
eagr 1461c26
configs as composition
eagr File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,7 @@ | |
|
||
pub mod client; | ||
pub mod error; | ||
pub mod params; | ||
pub mod quic; | ||
pub mod server; | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
//! HTTP/3 connection parameters | ||
|
||
/// HTTP/3 connection parameters builder | ||
pub struct Params { | ||
pub(crate) enable_webtransport: bool, | ||
pub(crate) grease: bool, | ||
pub(crate) max_field_section_size: u64, | ||
} | ||
|
||
impl Default for Params { | ||
fn default() -> Self { | ||
Self { | ||
enable_webtransport: false, | ||
grease: true, | ||
max_field_section_size: Self::DEFAULT_MAX_FIELD_SECTION_SIZE, | ||
} | ||
} | ||
} | ||
|
||
impl Params { | ||
/// Default max header size | ||
pub const DEFAULT_MAX_FIELD_SECTION_SIZE: u64 = (1 << 62) - 1; | ||
|
||
/// Set whether WebTransport is supported | ||
pub fn enable_webtransport(mut self, val: bool) -> Self { | ||
self.enable_webtransport = val; | ||
self | ||
} | ||
|
||
/// Set wether to send GREASE | ||
pub fn grease(mut self, val: bool) -> Self { | ||
self.grease = val; | ||
self | ||
} | ||
|
||
/// Set the maximum header size the endpoint is willing to accept | ||
/// | ||
/// See [header size constraints] section of the specification for details. | ||
/// | ||
/// [header size constraints]: https://www.rfc-editor.org/rfc/rfc9114.html#name-header-size-constraints | ||
pub fn max_field_section_size(mut self, val: u64) -> Self { | ||
self.max_field_section_size = val; | ||
self | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to put the WebTransport stuff behind a Feature Flag. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I thought about that too. But what if it's just for params and settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would put WebTransport completely behind a feature flag or maybe even in a separate crate. Iirc there was some discussion about this in #71.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the benefits of putting stuff behind a feature gate sometimes (smaller binary, faster compilation, etc). I totally agree we should feature-gate or separate major implementations of WT.
But configs and settings are lightweight and hard to separate. The benefit of putting those behind a feature gate seems limited. I'm 100% sure about this though. What do you think? @seanmonstar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about it more from a User perspective. Because it may lead to confusion when you are able to set a config which will do nothing without the feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it makes sense. And adding that may be too soon..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not had the time to read the WebTransport spec, so not sure what more is needed, but: does adding this at least allow for WebTransport to be proxied? If it's needed for a proxy to simply pass the data frames along, then seems fair to include it as part of the crate, perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think so. The setting would be required to be sent by both sides when establishing connection to create a WT session.