Hi all again, sorry I meant to send this to the quic list. Even though this is also relevant for masque and I already good some replies, here it goes.
Sorry for the cross-posting and confusing. Mirja On 15.10.20, 18:31, "Masque on behalf of Mirja Kuehlewind" <[email protected] on behalf of [email protected]> wrote: Hi all, We recently looked into HTTP CONNECT as specified in draft-ietf-quic-http (section 4.2.) and realized that all payload is required to be encapsulated in HTTP DATA frames after the CONNECT is completed. I can only guess that this is a “left-over” from HTTP/2 as in HTTP/2 this is required to realize multiplexing within the HTTP layer. However, for HTTP/3 multiplexing is realized by QUIC and as such it should be possible to simply forward all payload on a given QUIC stream after the CONNECT without the overhead of any additional HTTP framing. I believe that would actually be inline with how the CONNECT method worked in HTTP/1.1 and could simply save some overhead. I’m raising this on the mailing list to understand first if there are any other reasons to have the HTTP DATA frame required or if this is maybe an issue that is still worth raising and could be easily addressed at the current state. We are looking into this for similar use cases as for masque but in cases where only TCP is supported by the target server. For these use cases the proxy could easily support the HTTP CONNECT semantic but any additional HTTP semantics would not only be overhead but also increase complexity. So if it turns out there is no good reason to stuck with the requirement to have payload encapsulated in HTTP DATA frames, it should probably easy to just remove that requirement. Mirja -- Masque mailing list [email protected] https://www.ietf.org/mailman/listinfo/masque
