Contextual information from interceptors to request handlers

[madtrick]

Is your feature request related to a problem? Please describe.

This might already be possible but I haven't found a way to do it. Please advice.

What I would like to do is to pass additional, per-request information from the interceptors to the request handers. For example, I've an auth interceptor which validates the authentication params and I would like to attach some information (e.g. the user id) that's latter consumed by the request handler.

Describe the solution you'd like

A way to attach contextual information to requests.

Describe alternatives you've considered

• I can think of moving some of the logic outside of the interceptor into another module/function and call that from the request handlers. While it would work, it's not as clean as adding the data I need in the interceptors.
• I could also whatever information I want to the request metadata. I don't like this one so much because the boundaries between client metadata and my metadata are blurred. I could use a symbol to avoid clashes though (can't pass a symbol as metadata keys must be strings). And metadata only allows buffers or strings as values and I'd like to be possible to pass an object.

Additional context

This is possible in many other http api frameworks.

[madtrick]

What I ended up going for (while I don't find another solution) was to share a WeakMap between the request handlers and the interceptors. The interceptor would add whatever it needs to the map using the metadata as key, and the request handlers will get it when needed

[murgatroid99]

I would say that adding the information to the metadata is the intended solution. If you are concerned about distinguishing between metadata from the client and metadata from interceptors, you could use a reserved string prefix to distinguish them, the same way that we use the grpc. prefix to denote metadata produced by the gRPC library itself.

For complex objects, you could always JSON.stringify them, or spread the information across multiple metadata entries.

[madtrick]

Thanks for replying :)

For complex objects, you could always JSON.stringify them, or spread the information across multiple metadata entries.

Is there a reason why we can't add arbitrary data to the metadata? Having to serialize/deserialize or split the data and the reassemble it is not a great devex.

[murgatroid99]

The primary purpose of the metadata object is to represent data that can be sent in HTTP headers, and the limitations are a consequence of that. The ability to use metadata to pass information between interceptors is essentially an incidental result of how interceptors are designed.

I think it is also reasonable to use the solution you mentioned, with the data in an out-of-band object and the per-request key in the metadata.

I believe some other implementations have a "context" object that can be used more generally for this purpose, but I think retrofitting that onto the existing API would be non-trivial.