Repository navigation
[Bug] Redirects not being followed #744
Copy link
Copy link
Open
Labels
Needs: Author Feedbackstatus:waiting-for-author-feedbackIssue that we've responded but needs author feedback to closeIssue that we've responded but needs author feedback to close
Description
A bug has been introduced in version 1.13.0 of microsoft-kiota-http: redirects aren't being followed correctly.
For example, to download a driveItem from the MS Graph API (docs link) you make a call to /drives/{drive-id}/items/{item-id}/content and get back an empty 302 Found response with the Location header set to the actual download URL.
The below is an extract of the httpx logs from version 1.13.0. You can see the Location header is successfully returned, but no redirect is made.
DEBUG [2026-09-21 08:53:37] httpcore.http11 - send_request_headers.started request=<Request [b'GET']>
DEBUG [2026-09-21 08:53:37] httpcore.http11 - send_request_headers.complete
DEBUG [2026-09-21 08:53:37] httpcore.http11 - send_request_body.started request=<Request [b'GET']>
DEBUG [2026-09-21 08:53:37] httpcore.http11 - send_request_body.complete
DEBUG [2026-09-21 08:53:37] httpcore.http11 - receive_response_headers.started request=<Request [b'GET']>
DEBUG [2026-09-21 08:53:37] httpcore.http11 - receive_response_headers.complete return_value=(b'HTTP/1.1', 302, b'Found', [(b'Cache-Control', b'no-store, no-cache'), (b'Content-Type', b'application/octet-stream'), (b'Location', b'<link to the download location>'), (b'Strict-Transport-Security', b'max-age=31536000'), (b'request-id', b'44de6ff3-71fc-42e6-ad10-9670be4fcb0d'), (b'client-request-id', b'44de6ff3-71fc-42e6-ad10-9670be4fcb0d'), (b'x-ms-ags-diagnostic', b'{"ServerInfo":{"DataCenter":"North Europe","Slice":"E","Ring":"4","ScaleUnit":"001","RoleInstance":"DU2PEPF000107E5"}}'), (b'SPLogId', b'89553da2-e00b-3001-531f-268400ba5220'), (b'Date', b'Mon, 21 Sep 2026 08:53:37 GMT'), (b'Content-Length', b'0')])
INFO [2026-09-21 08:53:37] httpx - HTTP Request: GET https://graph.microsoft.com/v1.0//drives/<drive-id/items/<item-id>/content "HTTP/1.1 302 Found"
DEBUG [2026-09-21 08:53:37] httpcore.http11 - receive_response_body.started request=<Request [b'GET']>
DEBUG [2026-09-21 08:53:37] httpcore.http11 - receive_response_body.complete
DEBUG [2026-09-21 08:53:37] httpcore.http11 - response_closed.started
DEBUG [2026-09-21 08:53:37] httpcore.http11 - response_closed.complete
<END OF LOGS>
Even explicit setting the direct option when creating the various clients has no impact. i.e. if I do the following before making the call, the same error occurs.
auth_provider = AzureIdentityAuthenticationProvider(...)
client = GraphClientFactory.create_with_default_middleware(options=graph_request_adapter.options | {kioo.RedirectHandlerOption.get_key(): kioo.RedirectHandlerOption(should_redirect=True)})
adapter = msg.graph_request_adapter.GraphRequestAdapter(auth_provider, client=client)
ctx = msg.graph_service_client.GraphServiceClient(request_adapter=adapter)
...I think this issue was caused by commit d9180bb. Tagging RKS (@rksharma-owg) for visibility.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Needs: Author Feedbackstatus:waiting-for-author-feedbackIssue that we've responded but needs author feedback to closeIssue that we've responded but needs author feedback to close
Type
Projects
- StatusShow more project fieldsNeeds Triage 🔍
Activity
rksharma-owg commentedon Sep 22, 2026
Thanks for the report. I reproduced this without a live Graph account using
httpx.MockTransport: the first response is an empty 302 with aLocationheader, and the download endpoint returns 200.GraphClientFactorywith extension-based request options: 302, one transport call.request.options = {}attribute restored: 200, two transport calls.KiotaClientFactorywith extension-based request options: 200, two transport calls.The compatibility break is in
AsyncGraphTransport.handle_async_request: it only enters the middleware pipeline whenhasattr(request, 'options')is true. My change in d9180bb removed that attribute from Kiota's adapter when migrating options torequest.extensions["kiota_request_options"]. Consequently Graph-core bypasses the pipeline entirely; explicitly configuringRedirectHandlerOptioncannot help because the handler is never reached.This matches the existing report at microsoftgraph/msgraph-sdk-python-core#1128, which also covers URL replacement and other skipped middleware. I checked Graph-core main at ec79992519f708a014676584d5626ea8d733fe2c; the legacy guard is still present. Kiota's current main retains the extension-based adapter behavior.
Would you prefer a Kiota compatibility bridge for existing Graph-core releases, a Graph-core update that accepts both option representations, or both? I can add a regression through the Graph factory/transport boundary once the intended compatibility approach is confirmed. The legacy attribute above was a diagnostic control, not a proposed application workaround.
baywet commentedon Oct 15, 2026
Hi everyone,
Thank you for using the SDK and for reaching out.
I believe this has been addressed by the release of graph core 1.5.2. Please upgrade the dependency and let us know if you're still facing the issue.