Hook for Propagating Context/Headers

[jkratz55]

We have a microservice architecture and platform-mandated standards to propagate specific fields/headers throughout all calls.

Example:

Browser -> Service A -> Service B -> Service C

For tracing/logging, we propagate a few headers in every request, such as X-Request-ID, X-Forward-For, and X-Real-IP. Today we handle this by having a small wrapper around http.Client and adding a Before hook that has the following signature.

func(ctx context.Context, req *http.Request)

The before hook executes before calling Do method on http.Client. Basically, it provides an opportunity to modify the request before its sent to the server. We use it to pull values from the context and set the request headers. Example below:

func setHeaders(ctx context.Context, r *http.Request) {

	requestId := ctx.Value(ContextXRequestID).(string)
	realIP := ctx.Value(ContextXRealIP).(string)
	forwardFor := ctx.Value(ContextXForwardFor).(string)
	uid := ctx.Value(ContextUID).(string)

	r.Header.Set("X-Request-ID", requestId)
	r.Header.Set("X-Real-IP", realIP)
	r.Header.Set("X-Forwarded-For", forwardFor)
	r.Header.Set("X-App-User-ID", uid)
}

Since this is a common pattern, I'm looking for the best way to accomplish this pattern within requests. From glancing at the API/code I'm seeing three possible approaches.

1. Create a base Builder and clone it on every invocation populating the headers from the values in context.
2. Calling Request method to get the raw *http.Request, populating the Headers, and then calling Do method on the Builder
3. Using a RoundTripper implementation or requests.RoundTripperFunc to modify the requests to add the Headers.

Option 3 sounds dicey, though, looking at the docs in the standard library.

        // RoundTrip should not modify the request, except for
	// consuming and closing the Request's Body. RoundTrip may
	// read fields of the request in a separate goroutine. Callers
	// should not mutate or reuse the request until the Response's
	// Body has been closed.

What might be useful, although admittedly I haven't thought it all the way through, would be for the builder to provide a hook that took a context.Context and the raw *http.Request object. Then inside the Request method, before returning the request, the hook function could execute, allowing the headers to be populated based on values in the context.

[earthboundkid]

In terms of the warning from the standard library, that's why you need to clone a request before modifying it in a transport. See the UserAgentTransport for example, which adds a header to the cloned request.

Another option which you haven't listed is creating a request.Config like

func CtxConfig(ctx context.Context) request.Config {
  return func(rb *Builder) {
	requestId := ctx.Value(ContextXRequestID).(string)
	realIP := ctx.Value(ContextXRealIP).(string)
	forwardFor := ctx.Value(ContextXForwardFor).(string)
	uid := ctx.Value(ContextUID).(string)

	rb.Header("X-Request-ID", requestId)
	rb.Header("X-Real-IP", realIP)
	rb.Header("X-Forwarded-For", forwardFor)
	rb.Header("X-App-User-ID", uid)
  }
}

err := requests.URL(myurl).Config(CtxConfig(ctx)).Fetch(ctx)

But I think the custom transport is probably the best option.

[earthboundkid]

The config option is a little nicer now that there's requests.New:

func CtxConfig(ctx context.Context) request.Config {
  return func(rb *Builder) {
	rb.BaseURL("https://whatever.example/api/v2/")
	requestId := ctx.Value(ContextXRequestID).(string)
	realIP := ctx.Value(ContextXRealIP).(string)
	forwardFor := ctx.Value(ContextXForwardFor).(string)
	uid := ctx.Value(ContextUID).(string)

	rb.Header("X-Request-ID", requestId)
	rb.Header("X-Real-IP", realIP)
	rb.Header("X-Forwarded-For", forwardFor)
	rb.Header("X-App-User-ID", uid)
  }
}

var foo FooResponse
err := requests.
  New(CtxConfig(ctx)).
  Path("foo").
  ToJSON(&foo).
  Fetch(ctx)