Re: [Masque] HTTP DATA frames for HTTP CONNECT?

[Mirja Kuehlewind <[e-mail]>]

Hi David,

I was sending this request to exactly understand if or what the issues are/could be in not having the DATA frame. Can you maybe further explain which issue you see?

Mirja


From: David Schinazi <[e-mail]>
Date: Thursday, 15. October 2020 at 23:48
To: Mike Bishop <[e-mail]>
Cc: Mirja Kuehlewind <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT?

I agree with Alex, Lucas and Mike here.
Skipping HTTP frames entirely will cause issues.
The best solution IMO here is to define an extension
to HTTP/3 that defines a length-less DATA frame
(call it the DATUM frame perhaps) that extends until
the end of the stream. That would be beneficial for
HTTP GETs as well, not just MASQUE - so I'd
suggest bringing this to the QUIC or HTTP WG.

David

On Thu, Oct 15, 2020 at 11:24 AM Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:
(For example, see https://mikebishop.github.io/quic-external-data/draft-bishop-quic-external-data.html<https://protect2.fireeye.com/v1/url?k=fb1cf432-a5bc5aff-fb1cb4a9-86073b36ea28-e7aae7271a6c7151&q=1&e=b9526845-8195-474e-90cf-c7f907ea5f65&u=https%3A%2F%2Fmikebishop.github.io%2Fquic-external-data%2Fdraft-bishop-quic-external-data.html>.)

-----Original Message-----
From: Masque <[e-mail]<mailto:[e-mail]>> On Behalf Of Mike Bishop
Sent: Thursday, October 15, 2020 2:19 PM
To: Mirja Kuehlewind <mirja.kuehlewind=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Masque] HTTP DATA frames for HTTP CONNECT?

We had a similar conversation about the framing of large HTTP responses when the server knows it has no (more) pushes or headers to communicate.  There were proposals for DATA-compatible frames without a length that implicitly last until the end of the stream, as well as references to unframed unidirectional streams.  Ultimately, the WG decided against adopting any of those into the core protocol, but this seems like fertile ground for an HTTP/3 extension.

-----Original Message-----
From: Masque <[e-mail]<mailto:[e-mail]>> On Behalf Of Mirja Kuehlewind
Sent: Thursday, October 15, 2020 12:31 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Masque] HTTP DATA frames for HTTP CONNECT?

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque
--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque