Currently there is a patch in place for `requests.models.PreparedRequest.prepare_headers` to prevent the old `name.encode('ascii')` from being applied.
The if statement is very specific for python 2 and applies to requests < 2.0.0, which makes sense seeing this change ( https://github.com/psf/requests/commit/f5775594ccc0e2947b965c1fcf40747301a93974 ).
But there is also an or statement for NOT python2, making it always apply.
Not sure when this was needed, but it appears to work fine in python 3.
Going through git history of `requests`, I honestly cannot find any trace when this would have broken in python 3. The aforementioned change introduced the `to_native_string` for header keys. And the implementation and usage of that hasn't changed since. For our local setup using swiftclient, disabling the patch it all appears to keep working.
Desired situation:
Change the monkeypatch to only apply for the required version of requests.
The reason was hinted-at in https:/
$ swift post -m '☃:❄'
which swift has allowed ever since account/container metadata was introduced back in https:/
Now, setting metadata like that isn't a great idea. Doing it in my dev environment made `swift list` go from ~0.5s to ~100s (!) because py3's stdlib doesn't know how to handle the non-compliant header and aborts parsing -- see https:/
So the *real* value at the moment comes from being able to *clear* the non-compliant metadata after wondering why everything got so slow after switching to python3. Without it, users would have to either switch back to py2 or just use curl.