add response headers to context

[ofpiyush]

@chadawagner thank you for the PR.

We need to discuss this a little before deciding on the implementation.

@avinassh As far as I remember we intended to use the set_header and get_headers to be used by both the client and server to set headers from their respective direction. We never got around to implementing the overrides from server side though.

PS: From server's POV, Incoming request headers are stored in ctx under the RAW_HEADERS key

What do you both think about using set_header and get_headers directly?

[chadawagner]

@ofpiyush Sure, if you had some other implementation in mind that's fine, as long as we can set the response headers somehow. I was partly trying to mirror https://github.com/twitchtv/twirp/blob/main/context.go which has separate methods for accessing request and response headers, but also adding separate response headers so as not to change or break anything with how request headers currently work.

In my case we have microservices that are talking to each other, with common headers that identify a user or request trace etc. which need to be included in any requests that the RPC handlers might make as a client of other services. I have decorated each RPC handler method with a fn that gets the raw headers from the context and adds certain ones using set_header before the handler runs, so that within the handler code and any nested client calls to other services, the context headers are as expected/needed, and I can use the provided context directly in any client requests without further manipulation.

Maybe this was not the intended usage, and I'd be fine changing it if needed, but it sounds like it would break if set_header was suddenly for response headers as well. Since we can't know how anyone might be utilizing the current behavior, and since there are currently no custom headers being included in the response, imo the safest way to add such a feature would be to keep it separate from the existing set_header mechanisms

[ofpiyush]

Thank you for your response and thoughts on the topic!

In my case we have microservices that are talking to each other, with common headers that identify a user or request trace etc. which need to be included in any requests that the RPC handlers might make as a client of other services.

I do not work at the company anymore, so I can't be sure but I believe this is how Verloop uses them as well.

The only caveat here is to make sure users within your org understand that RAW_HEADERS is where they find the incoming headers and those are separate from what they get when they call get_headers.

it would break if set_header was suddenly for response headers as well.

I agree. We should keep them separate. 💯

I am somewhat conflicted between adding a context key vs a method directly on the context object.

I guess since we've diverged from the go implementation by providing helper methods for most common use cases, we can go one step further with response headers as well. 👍

[avinassh]

Thank you @ofpiyush and @chadawagner 🥳