W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 17 Aug 2021 13:53:19 +0900
Message-ID: <CANatvzwD9C28kCA1WHTJO1dxDUNthdAi86Tmrg+kgm_t84eFVg@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi, Amos,

Thank you for your comment.

2021年8月16日(月) 14:10 Amos Jeffries <squid3@treenet.co.nz>:

> IMO a mechanism that uses Client-Hints to modify the response type of
> TRACE method would meet requirements of this feature better than
> .well-known URIs.

While we can use  theTRACE method, I'm not sure if that simplifies things.

The key difference from the TRACE method and self-trace is that the former
works at resource level, while the latter works at the connection level.

TRACE has to be a special method because it changes how the resource
specified by the URI responds. In contrast, trace of the underlying
connection is not a property of an URI.

Based on that, I tend to believe that we can use the URI to designate a
service providing the self trace. If we look that way, use of a well-known
URI is a good fit, and it does not have issues like what happens with

> The TRACE mechanism has existed in HTTP since 1.1 so all agents should
> be able to support it cleanly by now.
> Agents not implementing the new mechanism will "fallback" to responding
> with details of what the responding server sees arriving: Via, Forwarded
> traces etc. Which may be of some use for troubleshooting even in absence
> of the self-trace information.
> Client-Hints comes with most HTTP handling behaviours pre-defined, so
> should not need re-defining for this new mechanism.
> Amos

Kazuho Oku
Received on Tuesday, 17 August 2021 04:53:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 17 August 2021 04:53:46 UTC