Skip to content

fix sse endpoint path preservation #504

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

Merged
merged 1 commit into from
May 16, 2025
Merged

Conversation

bhosmer-ant
Copy link
Contributor

Fix for the fix in #466, which was arbitrarily converting an "sse" endpoint suffix to a "messages" endpoint suffix.

Motivation and Context

bugfix

How Has This Been Tested?

updated erroneous existing test

Breaking Changes

no

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

Copy link
Contributor

@jerome3o-anthropic jerome3o-anthropic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me

@bhosmer-ant bhosmer-ant merged commit 6be4c60 into main May 16, 2025
5 checks passed
@bhosmer-ant bhosmer-ant deleted the basil/fix_path_preservation branch May 16, 2025 21:28
@@ -147,13 +147,7 @@ export class SSEClientTransport implements Transport {
this._endpoint = new URL(messageEvent.data, this._url);

// If the original URL had a custom path, preserve it in the endpoint URL
const originalPath = this._url.pathname;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this still might be incorrect, in the sense that the server can advertise any URI and expect the client to send POST messages there:

When a client connects, the server MUST send an endpoint event containing a URI for the client to use for sending messages. All subsequent client messages MUST be sent as HTTP POST requests to this endpoint.

spec link

I think the problem in modelcontextprotocol/inspector#313 et al is upstream of the client – specifically, the client should not be able to control the endpoint, but there's something in the inspector that's ignoring the correct endpoint (or the server transport is sending an incorrect endpoint value.)

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.

3 participants