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

[Lukasa]

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.

[Lukasa]

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.

[shin-]

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.

[Lukasa]

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.

[graingert]

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

https://github.com/kennethreitz/requests/pull/3738