Skip to main content

Protocol geeks might like the new proposals on how to do #QUIC over TCP/TLS: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams (called Streams) and then how to do #http3 over Streams: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams

Discussed on the #HTTPbis mailing list.

HTTP/3 on Streams

This document specifies how to use HTTP/3 on top of bi-directional, byte-oriented streams such as TLS over TCP. Discussion Venues This note is to be removed before publishing as an RFC.
IETF Datatracker
#http3 #quic #httpbis
in reply to daniel:// stenberg://

Peter Bindels
Peter Bindels
• •
since you're involved in this anyway; is there some kind of plan for making different streams in a quic connection have different protocols?
in reply to Peter Bindels

daniel:// stenberg://
daniel:// stenberg://
• •
@dascandy42 I have not seen any such proposals, no. I'm not sure I see the point since creating new connections over QUIC is fairly cheap
@Peter Bindels
in reply to daniel:// stenberg://

Peter Bindels
Peter Bindels
• •
Just a thought I'd had a few times. It feels wasteful and less secure to have multiple connections and handshakes when each connection itself has multiple streams.
in reply to Peter Bindels

daniel:// stenberg://
daniel:// stenberg://
• •
@dascandy42 a new QUIC connection can be setup with 0-RTT. A new stream can for example not use another port, so you would have to invent a new way to signal the destination.
@Peter Bindels
in reply to daniel:// stenberg://

Peter Bindels
Peter Bindels
• •

Isn't it disallowed to use a PSK for a different ALPN protocol?

But still, 1-RTT wouldn't be that harsh.

in reply to daniel:// stenberg://

Richard Levitte
Richard Levitte
• •

.....
Oh boy

I'll pass this along, I'm pretty sure I'll get a few exclamation points back.

⇧