You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apply the redirect rule to OAuth's own requests; clearer message for an https-to-http redirect
Second round of review follow-ups for the origin-scoped redirect handling:
- The rule "follow a redirect only within the request's origin, only when it
keeps the method" now lives in one predicate, next_request_within_origin,
which also declines a Location that carries userinfo (httpx2 would send it
as Basic auth).
- OAuthClientProvider and IdentityAssertionOAuthProvider apply that rule to
the requests their flows make (metadata discovery, registration, token,
refresh) through a small RedirectAwareAuth base, instead of those requests
following nothing. A redirect elsewhere is still handed to the flow as a
non-success, and the registration/token/refresh errors now name it.
- When the redirect budget (the client's max_redirects) is spent, the last
redirect is handed back unfollowed like any other, so a redirect loop fails
the one call with the usual error instead of raising TooManyRedirects out
of the transport.
- The "not followed" error for an https endpoint redirected to plain http on
the same host explains the likely cause (a TLS-terminating proxy the server
does not trust, often plus a trailing slash) and suggests the https form of
the location rather than the http one; locations are printed without query
or userinfo.
- docs: the OAuth and transports pages describe the shared rule; the ASGI
mounting example points clients at /notes/ (the path that does not redirect).
Copy file name to clipboardExpand all lines: docs/client/oauth-clients.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ The first time `Client` sends a request, the server answers `401`. The provider
83
83
84
84
After that it is quiet. Tokens come out of storage, an expired access token is refreshed with the refresh token, and only when none of that works does it run the flow again.
85
85
86
-
One transport rule applies to all of these requests: they are made while an MCP request is in flight, and like it they do not follow redirects to other addresses (they follow none at all), so the metadata, registration and token URLs must answer directly.
86
+
One transport rule applies to all of these requests: like the MCP request they run inside, they follow a redirect only when it stays on the same origin and keeps the method (a trailing-slash 307/308, say), and treat any other redirect as that URL not answering.
87
87
88
88
You wrote none of it. Two keyword arguments remain (`client_metadata_url` and `validate_resource_url`), and this file needs neither. `client_metadata_url` is the one worth knowing about; it gets its own section below.
0 commit comments