Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: Ability to Add Headers to Log #93

Closed
prabhakm opened this issue Sep 3, 2018 · 3 comments
Closed

Request: Ability to Add Headers to Log #93

prabhakm opened this issue Sep 3, 2018 · 3 comments
Labels
backwards-compatible *Shouldn't* require any backwards-incompatible changes to the header or payload formats

Comments

@prabhakm
Copy link

prabhakm commented Sep 3, 2018

Hi folks, John Riviello(github account: @JohnRiv) and I (Prabha, github: @prabhakm) have been following the NEL spec and are looking forward to being able to use it in browsers soon. One thing we would like to see added to the spec is the ability to include the values for headers we specify in advance that we are interested in.

In particular, we would like this because we make use of distributed tracing, and all of the major options in that space including but not limited to Zipkin, Jaeger, OpenCensus, Opentracing, etc -- make use of headers to pass tracing data along. If we could somehow include those tracing headers in the NEL report, then we would be able to directly associate a Network Error with a specific trace to be able to understand what a user experienced.

Any thoughts about this? Thank you.

@dcreager dcreager added the backwards-compatible *Shouldn't* require any backwards-incompatible changes to the header or payload formats label Sep 5, 2018
@dcreager
Copy link
Member

dcreager commented Sep 5, 2018

Up to know we've only talked about how to add additional server-generated metadata — and for that, we've suggested (for instance, in w3c/reporting#61) that the best way to do that is to add some extra URL parameters to your collector URLs. That would allow you to pass opaque data from the origin server, through the user agent, to the collector.

The tracing information is an interesting example, since the origin server can't know in advance which trace ID the user agent will create for the request, so the URL parameter technique won't work. We'd need something like you suggest — your NEL policy could include a list of headers to include in NEL reports, and the report payload would copy the values of those headers from the request.

My main worry is whether we'd need a list of unsafe headers that you could never add to your NEL policy — or conversely, a list of safe ones that are the only ones you're allowed to include. All of the request headers would be visible to server if the request succeeds, so this might not be necessary.

@JohnRiv
Copy link
Member

JohnRiv commented Sep 7, 2018

Thanks @dcreager. I noticed @AloisReitbauer from the W3C Distributed Trace Context Working Group expressed interest in figuring out how Server Timing and Distributed Tracing can work together... perhaps there's an opportunity to make Networking Error Logging and the Reporting API part of that discussion as well.

@dcreager
Copy link
Member

dcreager commented Sep 7, 2018

Thanks for the link, John! I agree that this could be a great place for us all to link up; I’ve followed up on that issue.

dcreager pushed a commit to dcreager/network-error-logging that referenced this issue Oct 23, 2018
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards-compatible *Shouldn't* require any backwards-incompatible changes to the header or payload formats
Projects
None yet
Development

No branches or pull requests

3 participants