>>> from requests import post
>>> r = post("https://example.com", files={"file-name": None})
However, when a param value or json field is None they are not included in the request body.
>>> from requests import get
>>> r = get("https://example.com", params={"file-name": None})
>>> r.request.url
This commit makes the beahviour consistent for files.
There was no way to determine what actual names were available outside
of looking at the source code. They were not listed in the documentation
or accessible through the interactive help.
In addition, doing `pydoc requests.status_codes` displayed some pretty
unhelpful information - the utf-8 encoding string was included in the
module name, there was no description, and internal variables used for
initialisation leaked into the module scope:
DATA
code = 511
codes = <lookup 'status_codes'>
title = 'network_authentication'
titles = ('network_authentication_required', 'network_auth', ...
This change prevents the internal variables from leaking, adds a
docstring (which has the side-effect of correcting the module name), and
appends information on the allowed status code names to the docstring
when the module is initialised.
The improved module documentation is then used in the API documentation
to provide another easy reference to the complete list of status codes.
* #4373, fix possible winreg value type difference
* add a test for ProxyOverride and ProxyEnable on win32
* add tests for winreg key ProxyEnable with two possible types
* fixing AppVeyor failures
According to RFC3986, the authority section can be empty for a given URL,
however, for a proxy URL, it shouldn't be. This patch adds a check to verify
that the parsed URL will have a valid host before creating the proxy manager.
Fixes#4353
While trying to get the prefix for an url, the url was lowered before comparing but the prefix not, so if it contains non-lowercase characters (eg. https://api.example.com/sOmE_WeiRD_pReFIX/), it won't match.
So that it's in line with the code. I saw the warning raised recently and had to dive into the code for exact compatibility, but I stopped after reading the comment rather than the code.
Maybe a better solution would be to surface the supported versions in the warning, but I see it was changed recently in https://github.com/requests/requests/pull/4144/
Ofek Lev