Returning undefined from discoverOAuthMetadata for CORS errors
#717
+35
−25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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`.
404100a to
2301ec9
Compare
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 <[email protected]>
pcarleton
approved these changes
Jul 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR #687 caused all web MCP client (e.g.
use-mcp) to fail for "legacy servers" (unless they had permissive CORS headers on 404 responses) and PR #692's fallback didn't quite work. I've fixed that so that CORS errors are handled more consistently, and the fallback works more often.The issue was if the server returns a 404 for
/.well-known/oauth-authorization-server/xyzthat didn't have theaccess-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 returnundefined.How Has This Been Tested?
Verified using
use-mcpinspector: https://inspector.use-mcp.dev/ and a server that requires auth (e.g. https://bindings.mcp.cloudflare.com/mcp)Breaking Changes
Types of changes
Checklist