Re: [Moq] Exploring HTTP/3

[Lucas Pardue <[e-mail]>]

Hi Spencer,

snipping for clarity

On Thu, Feb 9, 2023 at 6:16 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Lucas,
>
> On Thu, Feb 9, 2023 at 10:36 AM Lucas Pardue <[e-mail]>
> wrote:
>
>> Hey Spencer,
>>
> At the HTTP semantic layer, the version doesn't really matter, your
> request or response objects get transferred around. The same scheme value
> "https" works for all versions. Under the hood there's lots of differences
> and complexity of course. The Fetch API feels about the right layer of
> abstraction for most purposes.
>
>>
>> My sense so far has been that QUIC  is providing unique qualities that
>> the MoQ protocol (whatever it is) wants to harness. If that's true, HTTP/3
>> is a hard requirement of an HTTP-based MoQ protocol, then we'd have work to
>> do in the web platform to ensure its abstractions don't get in the way.
>>
>
> I understand less about Web APIs than I would like to understand - that
> could change, but so far, it hasn't. So, perhaps, I should be deferring to
> Bernard and Victor (two of the current WebTransport specification editors),
> but you know me. So I'll ask the question, and let more knowledgeable folks
> explain what I really meant, or just say "Spencer doesn't understand Web
> APIs".
>
> Looking at https://www.w3.org/TR/webtransport/#protocol-concepts, it
> looks like WebTransport is intended to run over HTTP/3, and in
> https://www.w3.org/TR/webtransport/#web-transport-configuration, there'sa *requireUnreliable
> *WebTransportOptions boolean attribute, that says, if "set to true, the
> WebTransport connection cannot be established over HTTP/2 if an HTTP/3
> connection is not possible."
>
> I understood your previous point to be that an application doesn't have a
> way to say "use HTTP/3 if you can". Was I misunderstanding your point, or
> the specification?
>

The W3C WebTransport API does give us more control over things, I think it
can work.

The shortest way I can articulate my point is that WebTransport over HTTP/3
is not HTTP. It switches operational modes.  Web APIs for dealing with HTTP
are different from WebTransport. For instance, fetch [1] using an example
from MDN [2]

fetch('https://example.com/movies.json')
  .then((response) => response.json())
  .then((data) => console.log(data));

This is a short-hand way to construct a Request object for the resource
/movies.json at the host example.com, using any transport and application
protocol that can fit the security needs of HTTPS (i.e. TCP+TLS+HTTP/1.1,
TCP+TLS+HTTP/2, QUIC+HTTP/3). If a successful response is returned by the
server, the remaining actions convert it to JSON and print it. There are
lots of other things that could be done with the response, like treating it
as a stream that can be piped to something else (like a web codec) etc.

The request could cause a new connection to be made to the server that is
authoritative for example.com, or it could be sent over an existing
connection if one existed. This decision making is mostly in the hands of
the implementation (they are subject to certain requirements, but they are
distracting). The important part is that the HTTP version is up to the
client (i.e. the browser). While the request can be customised to some
extent, there's not a way for javascript to directly ask "please issue this
request and ensure it is on a HTTP connection of version X, and that it is
coalesced in the same connection and if you can't do that, fail and give me
back control to decide what to do".

I'm not trying to pick on the web here either. There's many non-browser
clients that offer different abstraction levels for speaking HTTP. Some do
under-the-hood connection pooling. Some don't and let the user be very
specific about all facets of the request

I hope this makes it clearer what the differing capabilities I'm talking
about are. But if not I will try to explain it a different way, because we
might want to use that as input into a change request :-)

Cheers,
Lucas

[1] - https://fetch.spec.whatwg.org/
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch