Include custom request/response headers in reports #96

dcreager · 2018-10-23T15:05:29Z

The new request_headers and response_headers policy fields allow you to instruct the user agent to include the values of arbitrary request and response headers when creating a NEL report about a request.

Issue #93

The new `request_headers` and `response_headers` policy fields allow you to instruct the user agent to include the values of arbitrary request and response headers when creating a NEL report about a request. Issue w3c#93

dcreager · 2018-10-23T15:12:16Z

The main open question I have about this is whether there are any request or response headers that we have to prohibit for security or privacy reasons. I don't think we do, but I'd like to hear other people's opinions, too.

My reasoning: a NEL report is only supposed to contain information that the server would already have visibility into. Since the server can always see every request header sent by the user agent, and has full control over which response headers it sends back, then there isn't any new information that we could leak to the server owner using this mechanism.

To make sure that we handle the kinds of attacks mentioned in #74, we make sure to clear out any custom headers when downgrading a report (which happens when we have a policy for a particular domain, but can't verify that the domain owner is the same as the server owner).

dcreager · 2018-10-23T15:13:15Z

Adding several reviewers who are participating in the discussion on w3c/trace-context#69; please feel free to add others!

igrigorik · 2018-10-23T18:04:20Z

index.html

+        end user request, and uses a distributed tracing framework to correlate
+        events about all of these requests together.  The tracing framework
+        relies on the browser generating a unique trace ID for each outgoing
+        request, placing it in the request's <code>TraceParent</code> header.


This bit assumes the browser supports such a thing, but that's not the case today, nor is it clear where / how that will be defined. Should we omit this for now? If we want to keep this, I'd propose pulling this content out into a non-normative note, with a link to relevant discussion / WIP spec that attempts to defines this.

There was also confusion at TPAC about this — consensus was to discuss other use cases (and possibly remove/move this one as you suggest) to clarify that this feature is not specific to Distributed Tracing.

Changed the example to talk about cache validation (ETag and If-None-Match) instead.

igrigorik · 2018-10-23T18:49:13Z

index.html

+      data-lt="policy request headers">request headers</dfn> and a list of <dfn
+      data-lt-noDefault data-lt="policy response headers">response
+      headers</dfn>, each of which is a list of
+      header names.


To be consistent with IETF nomenclature and be more precise, let's use "header field names" throughout?

I was following Fetch, which uses "header name". (Though I should link this to the fetch definition)

igrigorik · 2018-10-23T18:51:11Z

index.html

+
+        <p>
+        The OPTIONAL <dfn><code>response_headers</code></dfn> member defines the
+        list of <a data-lt="policy response headers">response headers</a> that


Is it worth clarifying that you intend to append both header field name and value in these reports? Ditto for both request and response.

igrigorik · 2018-10-23T18:53:55Z

Re, security / privacy and exposing headers: I believe your reasoning makes sense. The server would see all these headers already, so we shouldn't be exposing anything new, short of allowing said origin to delegate delivery to alternate reporting endpoint.

That said, I'd love for @mikewest to sanity check before we land this.

dcreager · 2018-10-25T17:59:33Z

Re, security / privacy and exposing headers: I believe your reasoning makes sense. The server would see all these headers already, so we shouldn't be exposing anything new, short of allowing said origin to delegate delivery to alternate reporting endpoint.

We discussed this at TPAC today and the consensus was that this should be fine from a security/privacy standpoint.

dcreager

PTAL

dcreager · 2018-11-05T15:13:00Z

index.html

+      data-lt="policy request headers">request headers</dfn> and a list of <dfn
+      data-lt-noDefault data-lt="policy response headers">response
+      headers</dfn>, each of which is a list of
+      header names.


I was following Fetch, which uses "header name". (Though I should link this to the fetch definition)

dcreager · 2018-11-05T15:16:34Z

index.html

+
+        <p>
+        The OPTIONAL <dfn><code>response_headers</code></dfn> member defines the
+        list of <a data-lt="policy response headers">response headers</a> that


dcreager · 2018-11-05T15:38:55Z

index.html

+        end user request, and uses a distributed tracing framework to correlate
+        events about all of these requests together.  The tracing framework
+        relies on the browser generating a unique trace ID for each outgoing
+        request, placing it in the request's <code>TraceParent</code> header.


Changed the example to talk about cache validation (ETag and If-None-Match) instead.

igrigorik

👍

Awesome work on the detailed example. :)

dcreager · 2018-11-05T16:59:15Z

Thanks Ilya! Any other comments/questions before we merge this?

igrigorik · 2018-11-05T18:18:04Z

Looks good from this end.

Include custom request/response headers in reports

065ade5

The new `request_headers` and `response_headers` policy fields allow you to instruct the user agent to include the values of arbitrary request and response headers when creating a NEL report about a request. Issue w3c#93

dcreager requested review from AloisReitbauer, cvazac, igrigorik and yoavweiss October 23, 2018 15:12

igrigorik reviewed Oct 23, 2018

View reviewed changes

comments from igrigorik

7812794

dcreager commented Nov 5, 2018

View reviewed changes

igrigorik approved these changes Nov 5, 2018

View reviewed changes

dcreager merged commit 3562767 into w3c:gh-pages Nov 5, 2018

dcreager deleted the custom-headers branch November 5, 2018 19:28

dcreager mentioned this pull request Dec 6, 2018

Signed Exchange Reporting #99

Open

clelland mentioned this pull request Jun 21, 2023

Remove support for HTTP Trailers #146

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Include custom request/response headers in reports #96

Include custom request/response headers in reports #96

dcreager commented Oct 23, 2018

dcreager commented Oct 23, 2018

dcreager commented Oct 23, 2018

igrigorik Oct 23, 2018

dcreager Oct 25, 2018 •

edited

Loading

igrigorik Oct 26, 2018

dcreager Nov 5, 2018

igrigorik Oct 23, 2018

dcreager Nov 5, 2018

igrigorik Oct 23, 2018

dcreager Nov 5, 2018

igrigorik commented Oct 23, 2018

dcreager commented Oct 25, 2018

dcreager left a comment

dcreager Nov 5, 2018

dcreager Nov 5, 2018

dcreager Nov 5, 2018

igrigorik left a comment

dcreager commented Nov 5, 2018

igrigorik commented Nov 5, 2018

Include custom request/response headers in reports #96

Include custom request/response headers in reports #96

Conversation

dcreager commented Oct 23, 2018

dcreager commented Oct 23, 2018

dcreager commented Oct 23, 2018

Choose a reason for hiding this comment

dcreager Oct 25, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igrigorik commented Oct 23, 2018

dcreager commented Oct 25, 2018

dcreager left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igrigorik left a comment

Choose a reason for hiding this comment

dcreager commented Nov 5, 2018

igrigorik commented Nov 5, 2018

dcreager Oct 25, 2018 •

edited

Loading