Have you tried https://golang.org/pkg/net/http/httptrace/#ClientTrace?

See https://blog.golang.org/http-tracing

Do you have a concrete suggestion for what's missing in the httptrace package?

/cc @rakyll @tombergan

We could use httptrace if the transport request was sent into WroteRequest similar to how conn is passed into GotConn. However I don't think we should have to look into the trace to find the complete set of request headers.

I'd love it if Response.Request.Header included the extra headers set in transport.

I can create a code snippet if I'm not explaining this well, however my code will likely confuse you more!

I'd love it if Response.Request.Header included the extra headers set in transport.

That's not an option. We can't mutate that. It would break existing code, and possibly introduce data races. It's a backwards incompatible change.

First, let's make a list of the complete set of headers which can be added implicitly.

Only "Accept-Encoding" and "Connection", or more? And what do you need them for?

We have an internal application that polls a great many services over http for service health. When we detect a failure we capture as much information as possible to help diagnose the failure. Since we give users the option to set custom headers in their tests we provide them what we thought was a complete list of headers as part of the failure attributes.

Recently we had an issue using httptracer on an http/2 connection (where we did not realise we were falling through to http/2) and went down the path of diagnosing why we were re-using connections when we had explicitly disabled keepalives. The service receiving these polls dumped out the request including headers which included Accept-Encoding and Connection. If these were exposed as part of our failure we'd have had more insight.

I understand we can't mutate Request, however transport is not sending the same request as the user sets by adding these headers in flight. I'd be OK with using httptracer to expose this if possible though the purist in me thinks the response should include the complete request sent.

This is a reasonable feature request.

We could use httptrace if the transport request was sent into WroteRequest similar to how conn is passed into GotConn. However I don't think we should have to look into the trace to find the complete set of request headers.

I think httptrace is the best place for this, actually. It's not possible to mutate Request for the reasons that Brad mentioned. It's unfortunate that WroteHeaders() doesn't take an Info argument, and it's too late to change the signature. The possible solutions include:

1. Add Header to WroteRequestInfo. Might require copying the Header (I'd have to look).

2. Add WroteHeaderField(key, value). Would be called before WroteHeaders. Does not require copying the Header, but is slightly annoying to use because it's called once for each key/value pair.

3. Some combination of the above that only exports headers that are actually set or changed by the HTTP library.

Change https://golang.org/cl/67430 mentions this issue: net/http/httptrace: expose transport-added request headers for http/1.1

Gently pinging the issue here: @tombergan any ideas for this issue? -- as I can see that the CL has an unresolved -2 by the original author.

Change https://golang.org/cl/121236 mentions this issue: net/http/httptrace: add clarification never added to CL 67430

Change https://golang.org/cl/122816 mentions this issue: http2: fire httptrace.ClientTrace.WroteHeaderField if set

Change https://golang.org/cl/122591 mentions this issue: net/http: update bundled http2