-
Notifications
You must be signed in to change notification settings - Fork 323
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
Consider renaming or replacing http3only? #1744
Labels
Comments
annevk
added a commit
that referenced
this issue
Apr 5, 2024
This should be more future proof. Fixes #1744.
That makes a lot of sense. I created #1745. |
annevk
added a commit
that referenced
this issue
May 2, 2024
This should be more future proof. Also tidy up the language a bit. Fixes #1744.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the issue with the Fetch Standard?
In the context of WebTransport, the use of the term
http3only
in obtain a connection came up in discussion of w3c/webtransport#561.We've been trying to adhere to more transport agnostic principles, allowing developers to express their needs based on properties of the transport, rather than hardcoding a particular protocol or a version of a protocol.
In that context, the reason for requiring
http3only
was determined to instead represent the desire to obtain unreliable transport that can eliminate head-of-line blocking, perhaps we should use some spelling of the termrequireUnreliableTransport
.Filing an issue to discuss if we want to transition to something more transport agnostic in fetch as well when obtaining connections. What happens when we have HTTP/4? HTTP/3.1? What if HTTP/3.1 doesn't provide the same underlying transport properties? It seems like enshrining the protocol version itself as the name of the field leaves us in an undesirable position.
The text was updated successfully, but these errors were encountered: