- More specific expectations in test "uses custom fetch implementation from options"
* In sse.ts
- Import FetchLike from transport.ts
* In steramableHttp.ts
- Import FetchLike from transport.ts
- Export StartSSEOptions interface for testing
* In streamableHttp.test.ts
- import StartSSEOptions from streamableHttp.ts
- use StartSSEOptions instead of any in test "uses custom fetch implementation"
* In transport.ts
- Add FetchLike function type
nullish coalescing operator ?? instead of the logical OR operator || to handle the case where this?._eventSourceInit?.fetch or this._fetch might be null or undefined but not falsy
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
nullish coalescing operator ?? instead of the logical OR operator || to handle the case where this?._eventSourceInit?.fetch or this._fetch might be null or undefined but not falsy
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Previously the SSE connection would always default to the
`/.well-known/oauth-protected-resource` URI, ignoring the `resource_metadata`
portion of the `www-authenticate` returned in a 401.
Extract the metadata from the initial 401, so RS servers with
custom protected resource URIs (as in RFC9728, [section 3.1][1]))
continue to work as expected.
[1]: https://datatracker.ietf.org/doc/html/rfc9728#section-3.1
* add type and schema for protected resource metadata
* add private variable to keep track of
authorization server url to avoid fetching Protected Resource Metadata every time
* change auth flow to use authroization server and
add function to discover protected resource metadata
* add/modify tests for new added auth functions
* modify test to use the authorization server
* remove unused variable
* add resource parameter when building auth url
* Change resource to use the protected resource metadata
* resolve typo.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* Update src/client/sse.ts import.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove log.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* Update section title.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove log.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* remove resource parameter.
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
* make backwards compatibile
* s/resourceServerUrl/serverUrl/g for backwards compat
* fix test comment
---------
Co-authored-by: itsuki <itsuki.enjyoy@gmail.com>
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.com>
Co-authored-by: Paul Carleton <paulc@anthropic.com>
When an SSE client connects with a custom path (e.g., /api/v1/custom/sse),
ensure the endpoint URL maintains the same base path structure but with
/messages instead of /sse. This fixes issues where custom endpoints were
getting collapsed to the root path.
Should fix issues reported in modelcontextprotocol/inspector#313 and #296
Tests demonstrating the issue were added in PR #439🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
