10000 Incoming request headers in passed to callbacks via RequestHandlerExtra<ServerRequest, ServerNotification> by KKonstantinov · Pull Request #557 · modelcontextprotocol/typescript-sdk · GitHub
[go: up one dir, main page]

Skip to content

Incoming request headers in passed to callbacks via RequestHandlerExtra<ServerRequest, ServerNotification> #557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

KKonstantinov
Copy link

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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

Adding the headers as "requestHeaders" inside RequestHandlerExtra appears the appropriate place to put this, since it contributes to a non-breaking change.

@KKonstantinov KKonstantinov changed the title Request headers in extra Incoming request headers in passed to callbacks via RequestHandlerExtra<ServerRequest, ServerNotification> May 27, 2025
@KKonstantinov
Copy link
Author

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.

@ihrpr
Copy link
Contributor
ihrpr commented Jun 10, 2025

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 ihrpr added this to the HPR milestone Jun 10, 2025
@KKonstantinov
Copy link
Author

@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:

  • httpVersion
  • headers
  • method
  • url
  • statusCode
  • statusMessage

Let me know your thoughts and I'll update the PR.

@ihrpr
Copy link
Contributor
ihrpr commented Jun 11, 2025

@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:

  • httpVersion
  • headers
  • method
  • url
  • statusCode
  • statusMessage

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 authInfo and have only headers there (for now and add what is needed in the future)

The client itself might be working on a browser side, therefore any node:http deps (like IncomingMessage, which is the request), won't work.

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 🙏

@KKonstantinov
Copy link
Author

Thank you for the reply.

I'll add tests indeed. Will do a similar abstraction as authInfo for now then, called requestInfo, which for now will contain just the headers (and then add what is needed in the future as you said).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0