You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 term requireUnreliableTransport.
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:
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: