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
{{ message }}
Repository navigation
[Bug] HttpxRequestAdapter: The silent deprecation of base_url is actually a breaking change #501
The parameter base_url is still there but no matter what value you provide, it's ignored. We did not pass a value for http_client, and only specified the base_url like this:
We run this in a Fabric notebook where the version of the package was not pinned. So the moment it downloaded the new version, it failed with a misleading error.
To fix it, we had to do the following work around:
Reproduced on kiota-http 1.14.1 and on main (ce04532). It started in 1.9.4 with #481, which drops the argument on purpose and adds a test asserting it's ignored (test_httpx_request_adapter.py#L629-L631). 1.9.3 still honors it.
The error is only half of it. With a plain adapter the empty base URL turns into a relative request URL, so httpx fails with "Request URL is missing an 'http://' or 'https://' protocol." With the Azure auth provider it fails earlier with "Valid url scheme and host required", presumably the misleading error you saw (#470 had the same message).
With a generated client there's no error at all. Every kiota-generated Python client fills an empty adapter base_url with its default server (msgraph's sets https://graph.microsoft.com/v1.0). So the URL passed to the constructor gets replaced and requests quietly go to a different host.
The repro runs two local servers. "custom" is what gets passed as base_url, "default" stands in for a generated client's default server. Install with pip install microsoft-kiota-http==1.14.1 microsoft-kiota-authentication-azure==1.14.1.
AnonymousAuthenticationProvider, adapter.base_url=''
plain adapter: UnsupportedProtocol: Request URL is missing an 'http://' or 'https://' protocol.
generated client: reached ['default/ping']
setter: reached ['custom/ping']
AzureIdentityAuthenticationProvider, adapter.base_url=''
plain adapter: HTTPError: Valid url scheme and host required
generated client: reached ['default/ping']
setter: reached ['custom/ping']
On 1.9.3 adapter.base_url is the custom URL and all six requests reach custom.
#490 asks to remove the parameter, and the reply there asks whether it should be used instead. I'd go back to the pre-1.9.4 rule: an explicit base_url wins, otherwise take the client's. msgraph-core's BaseGraphRequestAdapter doesn't pass base_url, so that shouldn't bring back microsoftgraph/msgraph-beta-sdk-python#743, the bug #481 was fixing. I haven't run the beta SDK against it though. If removal is the plan, a DeprecationWarning when the argument is passed would at least end the silent part. Either way one PR can close this and #490, and I can send it once there's a call on the direction.
Activity
HardMax71 commentedon Oct 3, 2026
Reproduced on kiota-http 1.14.1 and on main (ce04532). It started in 1.9.4 with #481, which drops the argument on purpose and adds a test asserting it's ignored (test_httpx_request_adapter.py#L629-L631). 1.9.3 still honors it.
The error is only half of it. With a plain adapter the empty base URL turns into a relative request URL, so httpx fails with "Request URL is missing an 'http://' or 'https://' protocol." With the Azure auth provider it fails earlier with "Valid url scheme and host required", presumably the misleading error you saw (#470 had the same message).
With a generated client there's no error at all. Every kiota-generated Python client fills an empty adapter
base_urlwith its default server (msgraph's sets https://graph.microsoft.com/v1.0). So the URL passed to the constructor gets replaced and requests quietly go to a different host.The repro runs two local servers. "custom" is what gets passed as
base_url, "default" stands in for a generated client's default server. Install withpip install microsoft-kiota-http==1.14.1 microsoft-kiota-authentication-azure==1.14.1.Output on 1.14.1, and main gives the same:
On 1.9.3
adapter.base_urlis the custom URL and all six requests reach custom.#490 asks to remove the parameter, and the reply there asks whether it should be used instead. I'd go back to the pre-1.9.4 rule: an explicit
base_urlwins, otherwise take the client's. msgraph-core's BaseGraphRequestAdapter doesn't passbase_url, so that shouldn't bring back microsoftgraph/msgraph-beta-sdk-python#743, the bug #481 was fixing. I haven't run the beta SDK against it though. If removal is the plan, a DeprecationWarning when the argument is passed would at least end the silent part. Either way one PR can close this and #490, and I can send it once there's a call on the direction.