- 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>
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>
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>
* Returning undefined from `discoverOAuthMetadata` for CORS errors
This behaviour was already happening for the root URL, but the new `fetchWithCorsRetry` logic differed.
The issue was if the server returns a 404 for `/.well-known/oauth-authorization-server/xyz` that didn't have the `access-control-allow-origin`, a TypeError was being thrown. There was logic there already to handle a TypeError for a _preflight_ request (cause by custom headers), but not the fallback. I refactored so all combinations return `undefined`.
* Add test for CORS error handling that should return undefined
This test covers the scenario where both the initial request with headers
and the retry without headers fail with CORS TypeErrors. The desired
behavior is to return undefined instead of throwing.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix test comment
---------
Co-authored-by: Glen Maddern <glen@glenmaddern.com>
Co-authored-by: Paul Carleton <paulc@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Paul Carleton <paulcarletonjr@gmail.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
