Re: [Webtransport] Choosing the Transport

[Martin Thomson <[e-mail]>]

On Fri, Jul 24, 2020, at 11:42, Bernard Aboba wrote:
> It only takes a url as an argument (like the WebSocket constructor).  
> So the implication is that invoking the constructor creates a distinct 
> QUIC connection.  

How do you go from URL to a single connection?  fetch takes a single URL too, but those routinely use existing connections (in all protocol versions).

I also don't see the BlahTransport as having any inherent 1-1 mapping with connections.  If that is the case for Http[N]Transport, I would regard that as a design error.

> [BA]  Note that the Http3Transport  constructor doesn't have an 
> optional QuicTransport object as an argument, so that there's no way to 
> "share" a QUIC transport between Http3 (as used by say, fetch) and 
> Http3Transport.

Again, how did you get there?  I realize that there might be reasons why you might want to avoid sharing, like the rules we have for font fetching, but it doesn't naturally follow that you need a new connection for this.

> There is a reason why this isn't supported, even though it was 
> something that seemed quite desirable. HTTP/3 is very specific on how 
> it uses Stream IDs, so it would be quite tricky to have both the 
> WebTransport and another API like fetch sharing a QUIC connection. 

Now we're getting somewhere.  I agree that getting access to a bidirectional stream in HTTP/3 is tricky (and a unidirectional stream in HTTP/2 trickier), but surely these are spelling problems, not fundamental barriers to multiplexing.