New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requests v2.12.2 does not add parameters to URLs with schemes it does not understand. #3735

Lukasa opened this Issue Nov 30, 2016 · 4 comments


None yet
3 participants

Lukasa commented Nov 30, 2016

Follows from #3734.

When we patched to ignore all unrecognised schemes instead of just those that didn't begin http, we stopped handling parameters for those URLs. This may break some more benign uses such as http+unix, which wanted to add parameters to their URLs.

While this is inline with our intended policies (we do not understand URLs that have schemes we don't know anything about), this, along with the IDNA behaviour in v2.12.{0,1} will probably have broken a whole bunch of people using these non-standard URL schemes.

We should consider whether Session objects should have a registry of places to look for URL preparation based on scheme. This will allow people to opt-in to the HTTP-like processing of URLs, as well as to register their own.


This comment has been minimized.


Lukasa commented Nov 30, 2016

I should note that we have had this conversation with the docker-py folks before: see #1879.

Ultimately, there is a problem with how much people want us to understand URLs for non-standard HTTP schemes. People would like us to understand them enough to add query parameters, but not so much that we look for a hostname to internationalize.

I am as conflicted as I was three years ago.


This comment has been minimized.

shin- commented Nov 30, 2016

Thanks @Lukasa for chiming in and looking into this!

Being able to rely on requests to make docker-py work has been a great boon for us, especially the ability to handle different transport formats (HTTP/s, UNIX sockets, and more recently Windows named pipes) through the same interface is a powerful feature for us.

If you see any way we could keep this flexibility while making things easier on the requests library to support our use-case(s), I'd be happy to hear them and consider any changes.

Thanks again for your help.


This comment has been minimized.


Lukasa commented Dec 1, 2016

In the short term, I think we need to back out the breakage: kicking things over with @graingert convinced me that ultimately, whether we ever intended docker-py's usage of Requests to actually work, it has worked for more than three years. If we're going to break that, we should break it on purpose, rather than by accident.

So this issue remains worth discussing because we should solidify our position on this kind of thing for 3.0.0. Either we'll want to add explicit support for having HTTP-like schemes, or we'll want to add support for custom schemes to register URL processing handlers, or we'll want to drop support entirely as we (accidentally) did in v2.12.2. We should discuss what of those we think we want to do, and make sure there is a transition plan in place for projects like docker-py.


This comment has been minimized.


graingert commented Dec 1, 2016

In the short term, I think we need to back out the breakage


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment