Response Headers

[kcparker]

Hi,

I want to use ETags to avoid mid-air-collisions. During get requests the response should have an ETag header, so that a subsequent update request with contain that value in an ETag request header.

The value of the ETag will come from the service layer which is invoked by the Endpoint. I am using a grpc transport, and ServeGRPC does not provide a way for me to pass the value back from the Endpoint response. How should I get a value from the service layer into a response header using grpc transport? Should the context be returned from Endpoint or should there be another server after middleware that takes the response from the Endpoint?

Thank you.

[peterbourgon]

AFAIK, and please correct me if I'm mistaken, gRPC headers are comparable to, but not the same as, HTTP headers. Is there some prior art here? I would generally expect this to be solvable via SetResponseHeader.

[kcparker]

@peterbourgon the problem is the ctx passed into the service layer is immutable and would not have data in it that is added from the service layer by the time the ServerResponseFunc looked at the ctx.

Here is a look at the code in question.

response, err = s.e(ctx, request)
if err != nil {
	s.errorHandler.Handle(ctx, err)
	return ctx, nil, err
}

var mdHeader, mdTrailer metadata.MD
for _, f := range s.after {
	ctx = f(ctx, &mdHeader, &mdTrailer)
}

s.e(ctx, request) is where we would need to return the value for our header. We could return that value in the response but the response does not get passed to the s.after functions. The s.after functions get passed the ctx but s.e cannot modify that ctx.

[peterbourgon]

the problem is the ctx passed into the service layer is immutable and would not have data in it that is added from the service layer by the time the ServerResponseFunc looked at the ctx.

The ctxdata package I linked solves this problem. You inject a mutable value to the context at the top of the stack, write to that value deeper in the stack, and then read the written data on the way back out.

[dvavili]

Thanks @peterbourgon. Will give this a try and get back with results.

[dvavili]

Just wanted to add a note that I think it's cool how ctxdata solves for the immutable nature of context by using channels. 👍

[kcparker]

Thank you @peterbourgon this does solve our our problem.

[peterbourgon]

It's also worth noting that ETags by themselves don't solve this (or any) problem, it's only when they're combined with a caching middlebox that knows how to parse them that they have any effect. And it is IME rare that ETags make sense for Go kit applications — the caching/versioning semantics of HTTP are not usually a good match for the requirements of typical microservices.

[dvavili]

Like explained in the above comment, populating Etags is an issue that we are facing currently. Our situation might be a different than the norm due to the nature of our setup, but we've run into similar issues before with some features we've been trying to add. Basically add any information back to response headers based on response from service layer. This could be a valid case for someone utilizing grpc-gateway functionality along with go-kit grpc transport.

[basvanbeek]

Not directly visible here unless expanding the thread above is the actual answer how to solve this problem by @peterbourgon:

#1247 (reply in thread)

[peterbourgon]

Nice!

Contexts are tricky. When I figured out ctxdata it unlocked a lot of capabilities 👍