Hi Kazuho and Jana, How does an intermediary understand when this request is directed at them? In particular, a CDN or reverse proxy, vs. the origin? Currently, the text says 'When a server receives a GET request at the Self-Trace Well-Known URI...' which includes intermediaries by definition...
> To prevent this attack, servers SHOULD serve self-trace only when > HTTPS is being used. The assumption here is that when HTTPS is being > used, end-clients are directly connected to the server. I'm not sure that's a reasonable assumption; enterprise MITM proxies are pretty widely deployed. They may not currently implement h2 or h3, but that's not something we can rely upon. Finally, just my .02 on naming - I think that 'connection tracing' is more evocative of what's going on, vs 'self tracing'. 'Self' implies a role (client, server, etc.), but that's not what's being traced. Cheers, > On 13 Aug 2021, at 4:14 pm, Kazuho Oku <[email protected]> wrote: > > Hello folks, > > Today Jana and I have submitted a tiny I-D called > draft-kazuho-httpbis-selftrace. > > The draft specifies a well-known URI to be used for providing a trace of a > particular HTTP/3 connection (e.g., qlog) on that same HTTP/3 connection. > > One of the biggest hurdles in analyzing HTTP/3 performance issues is > obtaining traces that show the symptoms. That is because clients being > affected by issues have to coordinate with the server operators to collect > the traces. > > This PR solves the problem by defining a well-known URI for serving a trace > to the client on the HTTP connection that the client is using. When a user > sees an issue, they can collect the traces themselves and provide it to the > server operator. > > We have already implemented the feature in h2o, and doing so was easy, > assuming that the underlying QUIC stack already defines callbacks for > collecting trace events, see lib/handler/self_trace.c of > https://github.com/h2o/h2o/pull/2765. > > We also have a public endpoint; to try it out, first open > https://ora1.kazuhooku.com/test/self-trace/video-only.html (which starts > streaming a video), then open > https://ora1.kazuhooku.com/.well-known/self-trace. While the video is being > served, you would see the trace flowing through the well-known URI. > > At the moment, we are using a custom JSON format for the trace, but when gzip > compression is applied on-the-fly, the overhead of sending a trace alongside > ordinary HTTP responses is less than 10%. Therefore, we tend to believe that > this approach would work well in practice. > > Please let us know what you think - your feedback is very welcome. > > ---------- Forwarded message --------- > From: <[email protected]> > Date: 2021年8月13日(金) 14:53 > Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt > To: Jana Iyengar <[email protected]>, Kazuho Oku <[email protected]> > > > > A new version of I-D, draft-kazuho-httpbis-selftrace-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. > > Name: draft-kazuho-httpbis-selftrace > Revision: 00 > Title: Self-Tracing for HTTP > Document date: 2021-08-13 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/archive/id/draft-kazuho-httpbis-selftrace-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kazuho-httpbis-selftrace/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-selftrace > > > Abstract: > This document registers a "Well-Known URI" for exposing state of an > HTTP connection to the peer using formats such as qlog schema [QLOG]. > > > > > The IETF Secretariat > > > > > -- > Kazuho Oku -- Mark Nottingham https://www.mnot.net/
