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 12:53:59 +0900
Message-ID: <CANatvzwaWt1Ob0ZKENNFtSAupUENPsuFuhZEPzCR4HZ61UTfcw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
2021年8月16日(月) 10:50 Martin Thomson <mt@lowentropy.net>:

> On Mon, Aug 16, 2021, at 11:33, Ryan Sleevi wrote:
> > 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?
>
> No, I wouldn't assume anything of the sort.  The contract would be that
> this URL, no matter how it was resolved, would return a trace for the
> connection(s) on which the original request was made.
>
>
Martin, thank you for suggesting this. I like it.

I think this might be the correct thing to do, being uncertain if browsers
would send requests for traces over the same connection.

For privacy reasons (and probably also for security reasons), the
requirement we have is that only the client that created the connection
should be capable of fetching the trace.

In the original approach, we had the implicit binding between the
connection to be traced and the trace request - the trace request was sent
over the connection to be traced.

In the proposed approach (of using a response header field that points to
the URL from which the trace can be obtained), an explicit token can be
included in that URL (or the server can send an authentication token if
necessary).

-- 
Kazuho Oku
Received on Tuesday, 17 August 2021 03:54:23 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 17 August 2021 03:54:26 UTC