Comments (14)
That would require sending something over a stream (or datagram?). But the app can do that itself and we don't need to define anything. In other words, a higher-level WebSocket-like API could implement that on top of our lower-level API.
However, if we wanted to use transport parameters for this, we would want to add special support for it. Would this make sense as a transport parameter?
from webtransport.
Would this make sense as a transport parameter?
I actually wanted to just use the TLS ALPN fields for that (with a namespace prefix, of course, so that you can't negotiate non-web ALPNs with this).
from webtransport.
Oh, sorry, I didn't understand your first comment.
So basically you want to stuff extra things in the ALPN. Does that mean that the server sends back an ALPN value to the client (a response to the given ALPN)? And the client can send more than one ALPN value?
Sorry for my ignorance of ALPNs :).
from webtransport.
How does protocol multiplexing fit into the ALPN discussion? ALPN usage is clear if an RTCQuicTransport is only used for one purpose (e.g. CSQUIC, HTTP, etc.) but if we are to allow "pooled connections" where an RTCQuicTransport is used for HTTP and CSQUIC, then how what ALPN is used and does this open security holes?
from webtransport.
ALPN works the following way. Client sends a list of protocols that it supports, and the server picks one of them. In QUIC, if the client and the server don't have a protocol in common, it's a fatal error.
So, for example, the client could request applications "foo" and "bar" from the API, and the User Agent would send ALPNs "wq:foo" and "wq:bar" in its client handshake as an offer. The server would have to pick one of them or abort the connection.
from webtransport.
Seems like an interesting way to piggyback some info on the QUIC handshake. A web app could always do the same with messages/streams/datagrams after the QUIC handshake completes, but this is just slightly faster. So like all optimizations, the question is: is it worth it?
To know if it's worth it, it would be nice to know what kinds of subprotocols would be used. Basically, what use case would be faster that would make this extra complexity worth it?
from webtransport.
I agree that we should think hard about what exactly do we need here any why. I am not entirely clear on this myself, but I will note the following consideration.
Both HTTP and WSP allow the client to specify sub-endpoint within the server host (as /path). This is convenient in deployments for composing reasons: you can have two servers maintained by different teams running as standalone processes, and you can then multiplex them using a reverse proxy (e.g. nginx), dispatching by path or subprotocol. This does require a standardized way to specify sub-endpoint.
from webtransport.
My understanding of the use case: some JS wants to say QuicTransport("host", port, "chat") and another wants to say QuicTransport("host", port, "notifications"). It's the same host, but different services. Where do we put those services on the wire? The app could put that in a stream of its own, but that adds some app-level complexity and an RTT.
from webtransport.
One issue with it being in the ALPN is that it won't be encrypted, which might be a surprise and problem for the app.
from webtransport.
One alternative might be to do what we've always wanted to avoid: have QuicTransport allocate stream 1 and use that for sending sub protocols (and possibly other stuff). Maybe we should just reserve stream 1 for future extensiblity.
from webtransport.
If it's not encrypted, and we're OK with that, we might as well use QUIC transport parameters, right?
from webtransport.
Need to add optional third parameter to the RTCQuicTransport constructor.
from webtransport.
Notes from a discussion:
Why a URL 3rd parameter? A place for CSP. Why? Because CSP is based on URLs.
Why not a 3rd parameter on QuicTransport? The JS/wasm can always do that anyway, perhaps when they do auth (so it might not be so onerous)
Why not 3rd parameter URL? A lot of things will expect it's an HTTP request, and we don't want to deal with cookies and storage.
Alternative: use "quic://$host:$port"
from webtransport.
Why not a 3rd parameter on QuicTransport? The JS/wasm can always do that anyway, perhaps when they do auth (so it might not be so onerous)
So, I thought about this for a while, and I think I am currently leaning towards "add 3rd parameter" option.
From the design standpoint, our general goal has been roughly "provide the feature set one would get from using QUIC directly, but not more". So, for instance this principle bars cookies and HTTP auth, as QUIC by itself does not support those; but it does not preclude us from authenticating the server using WebPKI (in fact, we require that) or authenticating the client using a TLS certificate (we currently do not support that, but I do not see that much of a problem of supporting that if there are users who want that).
Multiplexing here is interesting because QUIC does support "third parameter" natively via ALPN, but we require ALPN to be fixed because of security restrictions. Thus, I feel like we should provide a replacement mechanism for this. The two options we've discussed so far are:
- Transmitting it as an ALPN suffix.
- Transmitting it together with origin on special stream.
I think the second option is preferable because then it gets encrypted.
from webtransport.
Related Issues (20)
- estimatedSendRate absent vs null HOT 1
- getStats() being rejected
- Quality of a bandwidth estimate HOT 16
- Allow more aggressive garbage collection HOT 5
- Should the constructor take http3Only or something more transport agnostic? HOT 10
- WebTransportSendStream's abortSignal algorithm doesn't make sense
- No write requests are being rejected on in-flight error HOT 2
- Should all fields in WebTransportConnectionStats be nullable? HOT 2
- Send algos contains normative MAY and SHOULD in non-normative notes
- Clarify what sending "completed" means e.g. wrt. flow control HOT 2
- How should the WebTransport constructor handles timeouts? HOT 5
- serverCertificateHashes really only allow if not pooled? HOT 10
- Remove dependency on "Data Recvd" state HOT 3
- What are "first-strong heuristics"? HOT 2
- WPT tests are needed for serverCertificateHash feature HOT 2
- Working with servers behind a NAT or on a local network (aka "p2p") HOT 2
- Relative URL in WebTransport constructor HOT 1
- Listening to event by event name HOT 6
- Keep connection on tab switch HOT 10
- wt.ready and wt.closed trigger unhandled rejections
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webtransport.