- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 14 Aug 2021 12:43:52 +1000
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Jana Iyengar <jri.ietf@gmail.com>
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 <kazuhooku@gmail.com> 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: <internet-drafts@ietf.org> > Date: 2021年8月13日(金) 14:53 > Subject: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt > To: Jana Iyengar <jri.ietf@gmail.com>, Kazuho Oku <kazuhooku@gmail.com> > > > > 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/
Received on Saturday, 14 August 2021 02:44:13 UTC