Re: [Webtransport] Choosing the Transport

[Victor Vasiliev <[e-mail]>]

On Fri, Jul 24, 2020 at 1:49 AM Martin Thomson <[e-mail]> wrote:

> On Fri, Jul 24, 2020, at 15:04, Victor Vasiliev wrote:
> > The questions raised regarding non-uniform support for features are
> relevant here, so this isn't completely free.
> >
> > What exactly do you mean by "non-uniform support for features"?
>
> Let's say that you like a particular extension to the protocol, but the
> server doesn't universally implement it across versions.  The worse case is
> where the extension works in one version, but not a protocol that you might
> otherwise prefer.  For instance, DATAGRAM support not being available in
> HTTP/3.
>
> This is just a natural consequence of building protocols up piecemeal.
> It's not a big deal, but it does tend to happen more with an existing
> protocol that you build on than a protocol you build from scratch.
>

I think the draft currently defines DATAGRAM as a requirement for
WebTransport over HTTP/3, so the question here would be something among the
lines of "what do we do when we have an active HTTP/3 connection in the
pool, but it has no WT support?".  I agree there's a lot of ambiguity in
this space right now, and it kind of exists between protocol space and the
API space.


>
> > I think the "origin model" question is automatically answered by the
> > URI scheme, since that would tell us if WebTransport can be, in
> > principle, same-origin to a Web page.
>
> I'm not sure that it is necessarily that simple.  This gets into the
> issues that Adam raised about cookies, and there are questions about CORS.
> It probably makes sense to recognize this as being exempt from CORS
> preflight on the understanding that support for the protocol implies an
> acknowledgment that ambient authority is NOT sufficient for authorization,
> but we also have to consider what state from the target origin is carried
> across into the WebTransport session.  Maybe we don't provide a way to
> carry cookies, but can we share connections?  Or session tickets?  I see
> from Bernard's response that the current thinking is to avoid this by
> avoiding connection reuse entirely.  I'm not yet convinced that this is the
> right answer.
>

I believe cookies are defined to be bound to a host-port tuple (since they
predate the origin model), meaning that the question is mostly just "do we
want to send them at all?", because the rules are otherwise clear.
Regarding CORS, I agree that a preflight is not necessary, and for what
it's worth, WebSocket does not do it already.
Sharing connections should probably follow the regular HTTP connection
reuse rules, which are nominally defined in RFC 7540
<https://tools.ietf.org/html/rfc7540#section-9.1>, but also depend on other
factors like the credentials mode
<https://fetch.spec.whatwg.org/#concept-request-credentials-mode> and
probably some other bespoke rules that aren't written down anywhere.
Session tickets in general are only bound by SNI, and for 0-RTT, by ALPN; I
don't think the behavior there depends on the application protocol in any
form.