Incoming request headers in passed to callbacks via RequestHandlerExtra<ServerRequest, ServerNotification> #557
Conversation
|
The Python SDK appears to expose the full request object to the tool/resource/prompt callback, so happy to update this PR to that effect for consistency if confirmed. |
yes, keeping it consistent would be great, thank you |
|
@ihrpr just to confirm. Exposing the full request will mean having it on the Transport interface, which is shared with the client also. The client itself might be working on a browser side, therefore any node:http deps (like IncomingMessage, which is the request), won't work. So we have to actually do an isomorphic approach that allows for this to work across both server & client side. Easiest we can do is our own interface extension for a request, and map just what we need (e.g. Node's IncomingMessage has sockets and others, where we really do not need all of that, rather picked ones like:
Let me know your thoughts and I'll update the PR. |
the way it works in Python SDK is though Generics, which will not work here. So yeah, I would not add dependency on node:http, ideally we have the same abstraction as
Not entirely sure I understand this part, the propagation of headers will be happening the same way as we do for authInfo and it will be on the server based on request received Separately, please can you add tests 🙏 |
|
Thank you for the reply. I'll add tests indeed. Will do a similar abstraction as On the comment about node:http, you answered my comment with the rest of your message. I'll add tests for this indeed, plus mocking the request object. Will get on this when I get the time in the following days. |
|
we need this merged! |
Incoming Request headers passed down to callbacks via RequestHandlerExtra
Motivation and Context
An application often times needs access to the original request headers, for example, whenever it is sitting behind a reverse proxy, and the reverse proxy is setting some headers itself.
One practical example: A trace ID / correlation header is generated at the API gateway / reverse proxy later, then passed to the actual remote MCP server. The MCP server needs to utilize the traceparent to store it in logs, etc.
How Has This Been Tested?
SSE and Streamable transport - resources and tools.
Breaking Changes
No breaking changes.
Types of changes
Checklist
Additional context
Adding the headers as "requestHeaders" inside RequestHandlerExtra appears the appropriate place to put this, since it contributes to a non-breaking change.