- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Sat, 14 Aug 2021 13:03:44 -0400
- To: ietf-http-wg@w3.org, Kazuho Oku <kazuhooku@gmail.com>
- Cc: Jana Iyengar <jri.ietf@gmail.com>
On 8/13/21 10:43 PM, Mark Nottingham wrote: >> 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. In fact, there are enterprise MITM proxies that inspect H2 already -- we have been helping to test them for a few years now. I do not know about H3 because Web Polygraph does not support H3 yet. Cheers, Alex. >> 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 17:03:59 UTC