Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

On Sun, Aug 15, 2021 at 7:59 PM Martin Thomson <mt@lowentropy.net> wrote:

> Rather than .well-known, would it help to negotiate a tracing endpoint for
> a request?


I don’t see why it would help? Isn’t this assuming the subsequent request
will be negotiated over the same transport connection, which is not
something guaranteed by any modern browser?

The approach suggested would suffer similar issues as, say, SDCH. For
example, imagine two parallel requests started on a single transport
connection. The first request establishes an alt-svc mapping, which lead
the browser to prime connecting to that alt svc. The second request
establishes/negotiates the Link Rel you just mentioned. However, the fetch
of the link rel/well known then happens on that newly established
connection.

Meanwhile, the original connection may end up getting reused for subsequent
queued requests (e.g. due to biases towards InitCwnd), or might round robin
through the original and alt-svc as requests are being satisfied.

Nothing prohibits this today, and there are already a host of timing
interactions in implementations of fetch() due to origin-wide
policies/behaviours that get configured/associated with individual
requests, that it’s not… unlikely.

Now, it’s possible that you’re suggesting the browser take special action
on encountering such relationships, beyond simply making it observable
(e.g. to JS/extensions). If that was the intent, then I think we’re in
agreement - that is, that browser networking stacks would have to be
especially aware of this work, and have special behavior to handle it, for
this to be predictably useful in browsers. That’s not at all an argument
against this work, but rather, an expression that modern browser networking
is complex enough that you don’t get things free and easy, whether directly
or through extensions: it has to be designed in and intertwined with every
other feature.