Raibek/requests-github-issues huggingface dataset:
fix appveyor

I don't know what's going on with Appveyor/Pipenv but it's no longer liking `-e .` installs out of the Pipfile. I went back to a version of Pipenv that we have successful builds for and it's still broken. I'd like to get builds fixed while we determine root cause.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=h1) Report
> Merging [#4647](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/9616f82905f86173477fdb3bf24f2f7228eed3a0?src=pr&el=desc) will **increase** coverage by `0.77%`.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4647/graphs/tree.svg?src=pr&token=mZGswIiXLa&width=650&height=150)](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master    #4647      +/-   ##
==========================================
+ Coverage   65.43%   66.21%   +0.77%     
==========================================
  Files          15       15              
  Lines        1548     1548              
==========================================
+ Hits         1013     1025      +12     
+ Misses        535      523      -12
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/adapters.py](https://codecov.io/gh/requests/requests/pull/4647/diff?src=pr&el=tree#diff-cmVxdWVzdHMvYWRhcHRlcnMucHk=) | `70.18% <0%> (+0.45%)` | :arrow_up: |
| [requests/models.py](https://codecov.io/gh/requests/requests/pull/4647/diff?src=pr&el=tree#diff-cmVxdWVzdHMvbW9kZWxzLnB5) | `77.2% <0%> (+2.25%)` | :arrow_up: |
| [requests/\_internal\_utils.py](https://codecov.io/gh/requests/requests/pull/4647/diff?src=pr&el=tree#diff-cmVxdWVzdHMvX2ludGVybmFsX3V0aWxzLnB5) | `75% <0%> (+6.25%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=footer). Last update [9616f82...9055b33](https://codecov.io/gh/requests/requests/pull/4647?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@nateprewitt @sigmavirus24 I’m wondering if the old school format of extras mentioned in https://github.com/requests/requests/issues/4646#issuecomment-389411076 is breaking when parsing with pip10...

I thought it might be Pip 10 when the builds started failing but we have successful builds with the same Pipfile and Pip 10 from a few weeks ago.

https://ci.appveyor.com/project/kennethreitz/requests/build/1.0.537/job/stejqhugrbl4010i
Add wheel hash for pluggy

- Lockfile was created when only the sdist was available

Thanks for the PR, @techalchemy. We've had issues in the past with resolution conflicts around this particular extras_requires string.

`'socks:sys_platform == "win32" and (python_version == "2.7" or python_version == "2.6")': ['win_inet_pton']`

I got things worked out and have a new lockfile we'll push up tomorrow once #4647 is merged. I'm going to close this out since that will probably cover other edge cases we're missing with our current Pipfile.lock. 

@nateprewitt is that what was causing the CI issues?

@techalchemy it is not, we don't use the lockfile in CI. I still have yet to determine what changed in the build environment.
import requests throws ValueError on urllib3.__version__.split

It may be an environment issue but I keep reproducing this error with latest requests:

```
➜  python3
Python 3.6.5 (default, Mar 30 2018, 06:41:53)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/requests/__init__.py", line 49, in <module>
    major, minor, patch = urllib3.__version__.split('.')[:3]
ValueError: not enough values to unpack (expected 3, got 2)
```

Here is a snip from `pip3 freeze`:

```
requests==2.18.4
requests2==2.16.0
rsa==3.4.2
urllib3==1.22
```

Please advise

Was due to version clashes which I just was able to fix, closing
Send http request, header passed dictionary type error

Summary.
requests2.18.1

## Expected Result
Send http request, header pass dictionary type OK

## Actual Result
The header when sending the http request is a dictionary, but an error occurred
```request.exceptions.InvalidHeader:` header value must be of type str or bytes, not <class 'dict'>```
## Reproduction Steps
The header I send is
```
  {
	"X-L-REQ-HEADER": {
		"lgId": "aaasssssssssssss",
		"userToken": "aaasssssssssssss",
		"appVersion": "1.4.0.1",
		"deviceType": 102,
		"reqVersion": 60300
	}
}
```
```python
import requests

url = "https://xxxx.com/v1/aaaaa/bbbbb/cccccc/dddddd"

querystring = {"pageNo":"1","pageSize":"20"}

headers = {"X-L-REQ-HEADER": {"lgId": "aaasssssssssssss","userToken": "aaasssssssssssss","appVersion": "1.4.0.1","deviceType": 102,"reqVersion": 60300}}


response = requests.request("GET", url, headers=headers, params=querystring)

print(response.text)

```

## System Information

    $ python -m requests.help

```
<paste here>
![image](https://user-images.githubusercontent.com/21286480/39863014-008d7d20-5478-11e8-8c8e-3324d79f958a.png)
```

This command is only available on Requests v2.18.1 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

Hi @lvorcool2016, as the exception says we need you to tell us what the header value looks like, either as a string or bytes string. Requests won’t try to serialize ambiguous values like a dictionary. I’m going to close this out since it’s intended behavior. Thanks for checking in!
Add check proxies not none in line 683

fixes #4635
In function merge_environment_settings before entering the loop

Hi @kartikeyaj0, thanks for contributing to Requests. From the issue and this pull request it's not immediately clear how you're entering this state. Proxies will be assigned to an empty dictionary if `None` is passed to the session, and the docstring explicitly states it must be a dictionary.

In the event a user somehow circumvents this, I think it's better to make sure we blow up here rather than silently failing. For that reason, I don't think we're going to accept this patch at this time. If you have more information on your issue, or believe there's a compelling reason we're missing, please feel free to let us know. Thanks!
Add long_description_content_type to setup.py

See:
- https://packaging.python.org/guides/making-a-pypi-friendly-readme/
- https://pypi.org/p/requests/

Duplicate of #4623 

Oh. Wait, it should be `text/x-rst`. Do you want me to open a new PR?

Or update this one!

My understanding was that if the readme is in RST, this isn't necessary to specify. Did the PEP change?

I think it's nice-to-have. 

I'll certianly reference it a lot, and it'll be educational for our users. 

@sigmavirus24 if you'd reopen, I'll make the change. :)

:crossed_fingers: this starts a new build on Travis

# [Codecov](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=h1) Report
> Merging [#4631](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/9b5071cdb666ba9e9b9444f8cd81a15bdf79349e?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4631/graphs/tree.svg?src=pr&token=mZGswIiXLa&width=650&height=150)](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4631   +/-   ##
=======================================
  Coverage   66.53%   66.53%           
=======================================
  Files          15       15           
  Lines        1560     1560           
=======================================
  Hits         1038     1038           
  Misses        522      522
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=footer). Last update [9b5071c...8bffd3d](https://codecov.io/gh/requests/requests/pull/4631?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Error reading Proxy certificates. (tlsv1 alert unknown ca)

Error reading Proxy certificates. It works for requests versions 2.11.1 and older.
But it does not work for 2.12.0 and newer versions.

## Expected Result

```
<Response [200]>
```

## Actual Result
```
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='cloud.recas.ba.infn.it', port=5000): Max retries exceeded with url: /v2.0/tokens (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_read_bytes', 'tlsv1 alert unknown ca')],)",),))
```

## Reproduction Steps

```python
import requests

body = '{"auth":{"voms":true}}'
headers = {'Accept': 'application/json', 'Connection': 'close', 'Content-Type': 'application/json'}
url = "https://<keystone_server>:5000/v2.0/tokens"
# it is a grid proxy certificate
cert = "/tmp/proxy.pem" # or cert = ("/tmp/proxy.pem", "/tmp/proxy.pem") 
requests.request('POST', url, verify=False, cert=cert, headers=headers, data=body)
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": "2.2.2"
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.13"
  }, 
  "platform": {
    "release": "4.4.0-121-generic", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "1010008f", 
    "version": "17.5.0"
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "1010006f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": true
}
```

The primary difference that looks potentially relevant to this [between 2.11.1 and 2.12.0](https://github.com/requests/requests/compare/v2.11.1...v2.12.0) is in urllib3. I believe that if the certificate authority file is false, we attempt to load the default file for the operating system. It seems that the code in [question](https://github.com/urllib3/urllib3/blob/30e9855307aaa9f9f09651f2bbddeb7350eed666/urllib3/util/ssl_.py#L334..L347) doesn't check the `cert_reqs` parameter which we [set to bypass verification](https://github.com/urllib3/urllib3/blob/30e9855307aaa9f9f09651f2bbddeb7350eed666/urllib3/util/ssl_.py#L334..L347). It also seems plausible to me that `load_default_certs` is resetting `cert_reqs` so that we do try to verify the TLS certificate when connecting.

Either way, this needs further investigation in urllib3.

This isssue is solved in urllib 1.23.
And it seems that you have updated you code to use update the urllib3 version in this commit
https://github.com/requests/requests/commit/ac944b7439009ffbf7a10dfee35202f1ac090e76.
I'm waiting it to be released.
Fix iter_lines boundary bug when CRLF straddles two chunks

In `Response.iter_lines`, if a `\r\n` sequence (the only multi-character line boundary) straddles two chunks, the `\r` and `\n` are treated as two separate boundaries. Consequently, `iter_lines` will yield one extra blank line, as an empty string.

This addresses the issue by checking if a chunk ends with `\r`, and when appropriate, leaving the trailing line in `pending` until the next chunk or EOF arrives.

Hi @nanotone, thanks for putting this together! This has actually already been addressed and is patched for Requests-3.0 (#3984). We won't be able to merge this into the current master branch because it's a breaking change for some users which isn't backwards compatible.
Booleans in form data are being incorrectly encoded in post requests

When sending form data, values which are booleans are encoded as "True" and "False" as opposed to "true" and "false". This is because of the urllib.parse.urlencode function.
Perhaps it is non standard to pass a boolean as form data, but I think this is non obvious to regular users. Maybe it should raise an exception or perform a conversion to lowercase.
 
## Expected Result
```
>>> data = {"key": True, "key2": "true"}
>>> req = requests.post("http://www.google.com", data=data)
>>> req.request.body
'key=true&key2=true'
```
## Actual Result
```
>>> data = {"key": True, "key2": "true"}
>>> req = requests.post("http://www.google.com", data=data)
>>> req.request.body
'key=True&key2=true'
```

## Reproduction Steps

Pass a dictionary with a key/value pair with a boolean value to the data param of a post.


In the future, please search **closed and** open issues before creating new ones that are duplicates. I'm not going to go find the duplicates right now. Given all of the possible representations of "True" on the internet, we can't really just pick one. Further, we rely on the stdlib to provide the serialization for this particular content type so we don't even do this directly. You should be thinking about how you want to pre-process the data you send. Feeding everything into requests and expecting it to magic its way to what you want isn't reasonable.
Strip whitespace for proxy urls, test for same. #4613

I'm not sure this is the right place to do this operation, but it does solve the problem. Or at least it passes the test that I wrote for it.

Quite likely I'm not reading them correctly, but as far as I can tell the other test methods related to proxies don't test something like a `requests.get()` call with the expectation of a successful result.

I found a ton of tests for error cases, though, and modeled the test for this situation on those, but it seems like there would be a better way.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=h1) Report
> Merging [#4627](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/fe8290b3d0ca21dd8ae5471a59a8bf13d3dcb31e?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `100%`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4627/graphs/tree.svg?height=150&width=650&token=mZGswIiXLa&src=pr)](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4627   +/-   ##
=======================================
  Coverage   66.62%   66.62%           
=======================================
  Files          15       15           
  Lines        1564     1564           
=======================================
  Hits         1042     1042           
  Misses        522      522
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/adapters.py](https://codecov.io/gh/requests/requests/pull/4627/diff?src=pr&el=tree#diff-cmVxdWVzdHMvYWRhcHRlcnMucHk=) | `70.18% <100%> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=footer). Last update [fe8290b...a3091c6](https://codecov.io/gh/requests/requests/pull/4627?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


In an effort to clean up the issue tracker to only have issues that are still relevant to the project we've done a quick pass and decided this issue may no longer be relevant for a variety of potential reasons, including:

* Applies to a much older version, unclear whether the issue still applies.
* Change requires a backwards incompatible release and it's unclear if the benefits are worth the migration effort from the community.
* There isn't a clear demand from the community on the change landing in Requests.

If you think the issue should remain open, please comment so below or open a new issue and link back to the original issue. Again, thank you for opening the issue and for the discussion, it's much appreciated.
Add test for stripping of proxy url.

Strip whitespace from proxy URLs in get_connection to resolve #4613.

I'm not sure this is the right place to do this operation, but it does solve the problem. Or at least it passes the test that I wrote for it.

Quite likely I'm not reading them correctly, but as far as I can tell the other test methods related to proxies don't test something like a `requests.get()` call with the expectation of a successful result.  

I found a ton of tests for error cases, though and modeled the test for this situation on those, but it seems like there would be a better way.
.. is not interpreted correctly with redirections

When a site redirects to an URL containing "/../", requests passes it verbatim instead of interpreting it.

## Expected Result

requests should remove the ".." component and the previous component, by interpreting the ".." as meaning "parent folder".
All real browsers do it. libcurl/curl (and wget) does it too.
Test for example https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Ffoo%2F%2E%2E%2Fget

## Actual Result

requests fails to interpret it like other HTTP clients do and passes the "/../" verbatim, leading to errors on servers, ranging from 500 errors to 404 errors (as for httpbin).

## Reproduction Steps

```python
import requests
r = requests.get('https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Ffoo%2F%2E%2E%2Fget')
print(r.status_code, r.url)
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.15"
  }, 
  "platform": {
    "release": "4.15.0-1-amd64", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "1010008f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": false
}
```

Hi @hydrargyrum, thanks for taking the time to bring this to our attention. This is actually a known issue and duplicate of #2982. We can’t currently resolve it in the Requests 2.x branch for backwards compatibility reasons. We have a todo for Requests 3.0 to resolve it, either by moving to the rfc3986 library for url parsing, or finding another alternative. For consolidation purposes I’m closing this in favor of the original ticket.
request to https server fails with bad handshake

Summary.

I am attempting to connect to an https server (unfortunately private internal server) which request.get() fails to connect, but curl succeeds. Specifically, I'm using gertty and attempting to connect to an internal gerrit server.

## Expected Result

python requests library succeeds to connect and allows me to work with the server.

## Actual Result

the connection fails with:

requests.exceptions.SSLError: HTTPSConnectionPool(host='<gerrit server>', port=443): Max retries exceeded with url: /gerrit/a/config/server/version (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_read_bytes', 'sslv3 alert handshake failure')],)",),))

## Reproduction Steps

```python
import requests

requests.get("gerrit-server")
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.0.2"
  },
  "idna": {
    "version": ""
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.14"
  },
  "platform": {
    "release": "4.15.15-300.fc27.x86_64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010006f",
    "version": "17.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1010008f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```

At first, I thought this was because the certificate was invalid, but I tried using curl, and it succeeded (well, ok it failed with unauthorized, since I haven't provided login credentials yet, but it did succeed the TLS handshake).

I used wireshark to compare the client hello message with the one from curl, and I found that the only major difference was that the successful curl request included more cipher suites, and the server appears to want to select one of those, so when the requests base client hello message is sent, it gets rejected.

Specifically, the server wants to use TLS_RSA_WITH_3DES_EDE_CBC_SHA, which is supported by curl, but not by the requests connection.

Any idea what is going on here, or whether there's a way to work around this issue in gertty? I am unable to use gertty with my internal server unless this is fixed.

I *believe* this issue is very similar to an issue in scrapy: https://github.com/scrapy/scrapy/issues/2717 as that was what led me down the path of checking the cipher suite to see if it was sending the same values.

Hi @jacob-keller, Requests no longer supports 3DES out of the box because of the known security vulnerabilities with it. There are several issues in the closed section (most notable #3774) describing how to work around this if you must. There's also a [blog post](https://lukasa.co.uk/2017/02/Configuring_TLS_With_Requests/) one of the maintainers wrote with more detailed information.

I would suggest talking with whomever is in charge of your infrastructure about updating the server, otherwise, the above solution will work.
Use multi-line import for __version__


Hi there @Stevoisiak !  Thanks for sending this PR along. We don’t accept stylistic changes, unfortunately as this project has its own style guide that we haven’t had a chance to document. 

@sigmavirus24 Should single-line imports over 100 characters be left alone as well?

https://github.com/requests/requests/blob/943a5c8e89db1758ae24adbbedacb3b05c32df4a/requests/compat.py#L58-L59

@Stevoisiak you can find the documentation on Kenneth Reitz’s code style [here]http://docs.python-requests.org/en/master/dev/contributing/#kenneth-reitz-s-code-style). We do allow lines over 100 and typically will not adjust the code base with linter changes unless there’s something significantly abnormal.
AppVeyor builds failing on master

For the past month, all pull requests to `master` have been [failing to build on AppVeyor](https://ci.appveyor.com/project/kennethreitz/requests/history).

From what I can tell, the build [started failing sometime around March 8th](https://ci.appveyor.com/project/kennethreitz/requests/build/1.0.383).

Commit https://github.com/requests/requests/commit/8f3f022c54db7c8348c84c079dfe7f7c354f1062 may have fixed the issue in the `3.0` branch, but the fix does not seem to have been merged to `master`.

## Expected Result

Pull requests should report a successful build.

## Actual Result

All pull requests report a build status of failure.

## Reproduction Steps

1. Submit a pull request to `master`.
2. Wait for AppVeyor to finish building
3. [Check the build status](https://github.com/requests/requests/pull/4616).

Hi @Stevoisiak, thanks for reporting this. We have a solution to address this in #4620.

@nateprewitt This seems to have fixed Appveyor, but now it looks like [Travis CI builds](https://github.com/requests/requests/pull/4616) may be failing.

@Stevoisiak, yes, we're aware. This is an issue with the recent release of Flask 1.0.1 which broke some pieces of the testing infrastructure due to external dependencies. It's currently being tracked in requests/httpbin#442.

@nateprewitt Thank you for the update. Closing this as resolved by #4620.
Add module docstring to __version__.py

Adds a docstring to `__version__.py`.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=h1) Report
> Merging [#4616](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/fe8290b3d0ca21dd8ae5471a59a8bf13d3dcb31e?src=pr&el=desc) will **decrease** coverage by `0.04%`.
> The diff coverage is `0%`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4616/graphs/tree.svg?width=650&height=150&src=pr&token=mZGswIiXLa)](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master    #4616      +/-   ##
==========================================
- Coverage   66.62%   66.58%   -0.05%     
==========================================
  Files          15       15              
  Lines        1564     1565       +1     
==========================================
  Hits         1042     1042              
- Misses        522      523       +1
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/\_\_version\_\_.py](https://codecov.io/gh/requests/requests/pull/4616/diff?src=pr&el=tree#diff-cmVxdWVzdHMvX192ZXJzaW9uX18ucHk=) | `0% <0%> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=footer). Last update [fe8290b...5d5fb43](https://codecov.io/gh/requests/requests/pull/4616?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


this module is fine as–is, but thank you for you contribution!
update json param's description to avoid confusion

- the Request class doesn't accept JSON, but a JSON serializable object

Closing and re-opening to trigger a rebuild on AppVeyor

# [Codecov](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=h1) Report
> Merging [#4612](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/2de907ad778de270911acaffe93883f0e2729a4a?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4612/graphs/tree.svg?token=mZGswIiXLa&src=pr&width=650&height=150)](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4612   +/-   ##
=======================================
  Coverage   90.18%   90.18%           
=======================================
  Files          15       15           
  Lines        1548     1548           
=======================================
  Hits         1396     1396           
  Misses        152      152
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/api.py](https://codecov.io/gh/requests/requests/pull/4612/diff?src=pr&el=tree#diff-cmVxdWVzdHMvYXBpLnB5) | `81.81% <ø> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=footer). Last update [2de907a...1a93b7a](https://codecov.io/gh/requests/requests/pull/4612?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Actually, @Obeyed would you mind rebasing this onto the current master branch?

Done! :+1: 

Since we don't need to worry about the tests with this change, I'm going to merge so it doesn't get out of sync again. Thanks again for contributing to Requests, @Obeyed!
Fix handling of zero-length files

This was previously fixed in e7c9bbb96 and broken again in
4c82dbab6fc. Add a comment this time to prevent people from breaking
it again.

Ok, this actually runs afoul of some tests. Interesting.

Hi @MarcSchmitzer, we use content-length of 0 internally to represent data of indeterminate size. This is sent using `Transfer-Encoding: chunked`. It's advised you don't provide a Content-Length when using Requests, since it should always be handled internally. As we say in the [docs](http://docs.python-requests.org/en/master/user/quickstart/#custom-headers), we will override the Content-Length header at will.

If you MUST pass a custom content length for some reason, I'd suggest using the PreparedRequests workflow. You can modify the headers on the PreparedRequest to be what you'd like and then send it.

Thanks for taking the initiative to try to fix this though. I'm going to close this out since it's something we won't be changing in the near future.

I guess to clarify, if you've found what you think is an actual bug around zero length files, please feel free to open an issue. A few initial tests suggest everything is handled fine and we send `Content-Length: 0` when it's possible to determine.

Yes, I do believe this is a bug in requests. I am not setting the content-length header from the outside, but rather providing an empty file object as the request body. Will open an issue.

Thanks for looking at this anyway.

@MarcSchmitzer, "empty" file objects aren't necessarily always empty in Python, which is why we use `Transfer-Encoding: chunked`. This is a valid method for transferring the file to the server.

If your server or use case requires that a Content-Length must be passed, modifying the PreparedRequest is likely what you'll need.

Some other issues for reference before opening a new one:
#4404
#3977

Ok, thanks again for your responses.

If you're interested, the problem is in combination with boto3/s3transfer. You could say it is really their bug, only they're currently vendoring a requests version (2.7.0) that behaves differently and doesn't trigger the bug. I'm only running into it because Debian undoes the vendoring and the requests version on Stretch (2.12) triggers it. Guess I'm going to go talk to the boto3 people.

That sounds like the boto3 are being explicit in what they're supporting and your linux distribution packager is ignoring that and saying "Hey this configuration seems to work!" which means that you're not really getting boto3. I'd be unsurprised if there were odd custom patches attached to your packages that you're getting as well such that requests isn't really requests either.
When POST ,  A dictionary type data will auto urlencode

Summary.

## When the POST data is a dictionary type

Requests will aoto URLencode it.

For example : 
```
postdata = { "url" : "https%3A%2f%2fwww.google.com" }
```

## Actual Result

When my post data have URLencoded data what include URL .

The actual post data is 
```
url=https%253A%252f%252fwww.google.com
```

## Search source code
models.py
```python

def _encode_params(data):
    """Encode parameters in a piece of data.

    Will successfully encode parameters when passed as a dict or a list of
    2-tuples. Order is retained if data is a list of 2-tuples but arbitrary
    if parameters are supplied as a dict.
    """

    if isinstance(data, (str, bytes)):
        return data
    elif hasattr(data, 'read'):
        return data
    elif hasattr(data, '__iter__'):
        result = []
        for k, vs in to_key_val_list(data):
            if isinstance(vs, basestring) or not hasattr(vs, '__iter__'):
                vs = [vs]
            for v in vs:
                if v is not None:
                    result.append(
                        (k.encode('utf-8') if isinstance(k, str) else k,
                         v.encode('utf-8') if isinstance(v, str) else v))
        return urlencode(result, doseq=True)
    else:
        return data

```


Hi @FuckTheLife, the default functionality of Requests is to treat dictionaries passed to the `data` param as multi-part form data which will end up urlencoded. This is what you’re seeing here and what we’d expect. I would suggest either passing strings that aren’t pre-escaped or making a string representation of exactly what you want and passing that in place of a dictionary.

I’m going to close this out since there doesn’t appear to be an issue.

@nateprewitt `multipart/form-data` only happens when `data` and `files` are present. When a dict is passed to `data` we `application/x-www-form-urlencoded` it. The behaviour is still correct, though.
Nicer URL formatting with lists

# Nicer URL formatting with lists

### Purpose

Using `['https://example.com', route1, route2]` as URL parameter as compared to `'https://example.com/{}/{}'.format(route1, route2)` or `'https://example.com/'+route1+'/'+route2`

### Examples

```python
import requests

slug = 1
r = requests.get(['https://api.jikan.me/anime', slug])
r.url
# 'https://api.jikan.me/anime/1'

category, item = 'jokes', 'random'
r = requests.get(['https://api.chucknorris.io', category, item])
r.url
# 'https://api.chucknorris.io/jokes/random'
```

Hi @sayanarijit, thanks for the interest in contributing to Requests! Unfortunately, the Requests API is more or less frozen at this point, so I don't believe we'll be able to merge this. It should be easy to accomplish what you're looking for by wrapping the list in a join though, so the additional overhead for users wishing to do this is minimal. Thanks again for putting this out there!
proxies in session not taken into account

When creating a session object, and setting proxies information, the proxy information is not used in subsequent requests:

SESS = requests.Session()
SESS.auth = (USER, PWD)
SESS.verify = False
SESS.proxies = {'https': None}

## Expected Result

SESS.get(URL + '/' + ENDPOINT)

should bypass the proxy and be able to resolve the internal URL.

## Actual Result

502: notresolvable for url

But passing the same proxy information to the get works:
SESS.get(URL + '/' + ENDPOINT, proxies={'https': None})

works as expected

## Reproduction Steps

```python
import requests
SESS = requests.Session()
SESS.auth = (USER, PWD)
SESS.verify = False
SESS.proxies = {'https': None}

```

## System Information

requests 2.13.0
python 3.5.2
Fedora 20

Hi @navidof, before we dig too far into this, can you confirm this is still an issue in 2.18.4 with urllib3 1.22?

Requests 2.13 is fairly old now and there’s been some proxy work done since then.

Hey again @navidof, I'm unable to reproduce this with 2.18.4 and since this hasn't seen an update in the last month, I'm going to close it out.

Hi Nate,

Thanks for your time, I didn't know how to test with another request package, anyway it's not possible for my use case to use another version.
The workaround is simple, so no worries if it's not fixed in my version.

Regards,
Navid

----- Mail original -----
De: "Nate Prewitt" <notifications@github.com>
À: "requests/requests" <requests@noreply.github.com>
Cc: "navidof" <navidof@free.fr>, "Mention" <mention@noreply.github.com>
Envoyé: Dimanche 20 Mai 2018 21:17:00
Objet: Re: [requests/requests] proxies in session not taken into account (#4599)



Hey again @navidof , I'm unable to reproduce this with 2.18.4 and since this hasn't seen an update in the last month, I'm going to close it out. 

— 
You are receiving this because you were mentioned. 
Reply to this email directly, view it on GitHub , or mute the thread .
Sessk

Summary.

## Expected Result

What you expected.

## Actual Result

What happened instead.

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
<paste here>
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).
Migrate to new PyPI website

According to [1], the PyPI website of pypi.python.org has changed
to https://pypi.org. This patch updates all references to the
legacy site.

[1] https://pythoninsider.blogspot.ca/2018/04/new-pypi-launched-legacy-pypi-shutting.html

Signed-off-by: Eric Brown <browne@vmware.com>

Hi @ericwb, this is already being addressed in #4596. Thanks for the initiative.
OSError / Image.open(BytesIO(r.content))

Summary.

## Expected Result

http://docs.python-requests.org/en/latest/user/quickstart/?highlight=binary#binary-response-content

```py
from PIL import Image
from io import BytesIO
i = Image.open(BytesIO(r.content))
```

```
Traceback (most recent call last):
  File "X:/study/test.py", line 7, in <module>
    i = Image.open(BytesIO(r.content))
  File "C:\Program Files\Python35\lib\site-packages\PIL\Image.py", line 2590, in open
    % (filename if filename else fp))
OSError: cannot identify image file <_io.BytesIO object at 0x0000000003471AF0>
```

python : 3.5.1
OS: Windows 7

I don't know how to solve it , give me a hand ,Thanks .

Hi @Liuzhj, this appears to be a request for help rather than a defect report for Requests. We recommend directing usage questions to [StackOverflow](https://stackoverflow.com) for assistance.

To help direct your question, it looks like you’re either misusing `image.open` or `r.content` is not an image. Either way the problem seems to lie outside of Requests.

hi @nateprewitt 

this [**url**](http://docs.python-requests.org/en/latest/user/quickstart/?highlight=binary#binary-response-content)  is official of Requests。

this code is copy from official documents, but is can't running 

![image](https://user-images.githubusercontent.com/14147011/38914404-cc7bcdc4-4311-11e8-9217-c7f355ecfdd2.png)



@Liuzhj as I said the value of `r.content` is not an image `pillow` can parse then. Please direct further questions on usage to StackOverflow, thank you!
`Collections.Callable` DeprecationWarning

Summary.
Python 3.7.0b3 has a new warning:
```text
.../python3.7/site-packages/requests/models.py:177: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  if isinstance(hook, collections.Callable):
```

## Expected Result
Need to change this line (and other references) to `if isinstance(hook, collections.abc.Callable):`

What you expected.

## Actual Result

What happened instead.

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.0b3"
  },
  "platform": {
    "release": "16.7.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1010007f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

Hey @hsolbrig, this is actually a duplicate of #4494 and we have a PR in the queue to address this. Next time please make sure to check issues and pull requests before opening a new one. Thanks for taking the time to bring this to our attention though!
Making a request with multipart/form-data (file=) should throw an error if the barrier defined in the headers does not match

I am unable to make a pull request at this time, but I think this should be added. The server will not understand the request if the content-type header's barrier= is not the same as the one generated by requests. At the very least there should be a warning.

Please provide us with the output of

```
python -m requests.help
```

If that is unavailable on your version of Requests please provide some basic information about your system (Python version, operating system, etc).

Additionally, this appears to be a duplicate of several issues. In the future, please search **closed and** open issues before creating new ones that are duplicates.
response.text is returning with header values.

Summary.
response.text is returning with header values.
## Expected Result
We are expecting only response content. but getting with header as well. Could you please help us to solve this issue ?
response.text  => {"@odata.context":"/redfish/v1/$metadata#ServiceRoot.ServiceRoot"}

## Actual Result
Getting response header with response.text like below
HTTP/1.1 200 OK
Content-Length: 807
OData-Version: 4.0
Content-Type: application/json
Date: Fri, 13 Apr 2018 04:38:07 GMT

{"@odata.context":"/redfish/v1/$metadata#ServiceRoot.ServiceRoot"}

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.7.1"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.12"
  },
  "platform": {
    "release": "4.4.0-93-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1000207f",
    "version": "16.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

Hi @selvaraju, we don’t modify the body so it’s unlikely Requests is doing anything other than returning what the server sent.

We’ll need you to provide a reproduction script in order to investigate. Until then, I don’t know if there’s anything we can do here.

Hi @selvaraju, since this hasn't received a response, I'm going to close this out for now. Please feel free to reopen when you have a reproduction that shows the issue isn't related to the server you're connecting to. Thanks!

Thank you.  It was working fine python3. not in 2.7.it worked fine if we put some wait before calling request api
PEM lib SSL error

Summary.

See https://github.com/requests/requests/issues/3702

What you expected.

A correct connection or failure to verify ssl error

What happened instead.

SSL library traceback

```
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 67, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 53, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 447, in send
    raise SSLError(e, request=request)
SSLError: [X509] PEM lib (_ssl.c:2831)
```

Reopening this previously closed issue.

Hi @kevr, thanks for taking the time to open this. So this error is a cert problem, as stated in the other ticket. We'd need the exact version of Python 2.7 you're using but it's likely coming out of [this function](https://github.com/python/cpython/blob/a61f5da54772b0ea6a7eccf21df08e61585ef712/Modules/_ssl.c#L2828-L2884). While the problem is pretty easy to find with a google search, I agree that the error message leaves something to be desired.

Since this exception is being raised from the standard library, the only fix is likely wrapping it and rethrowing a clearer message. If that work was done, it would be handled at a layer lower than Requests though. Either in [urllib3](https://github.com/urllib3/urllib3) or more likely in pyopenssl/cryptography. I'd suggest raising an issue there. Thanks!

Thanks for the quick response @nateprewitt -- I understand this is a certificate issue, however, I don't see a specific error message as to why; I guess the code basically says that what's being loaded is not in ASN1 or PEM format. Alright, thank you a lot.
allowing params to get requests on session

Simple fix to get method of Session class allowing it to receive params, just as requests.get would allow

Hi @ggalves Can you share a bit more about what makes this PR necessary? `Session.get` already accepts `params` via `**kwargs` and passes them on appropriately to the best of my knowledge. Is something not behaving as you expect it to?

Hi @sigmavirus24, I'm sorry, you are right, it's unnecessary.

I couldn't reproduce my problem anymore, i did the PR on a hurry and must have mislooked something lol. I'll try later to reproduce it and open an issue if necessary. 

You can close this PR, my apologies.
requests.get() never timeouted when https proxy connect success but not response data.

requests.get() never timeouted when https proxy connect success but not response data.

1: we create the server at port 4444 but not response any data.
bash$  nc -l 4444
2：and then call request.get with https proxy
bash$ python3
 import requests
requests.get("https://www.baidu.com", timeout=5, proxies={"http":"http://127.0.0.1:4444", "https":"http://127.0.0.1:4444"})

this command never return in urllib3.
it block in HTTPSConnectionPool::urlopen, because HTTPS will call
HTTPSConnectionPool::_prepare_conn() to prepare_conn( note http proxy never do this),
and send "CONNECT ... HTTP/1.0"  and blocked in response.
because of socket.create_connection's timeout is None means "never timeouted",
backstrace to requests, it new HTTPSConnectionPool() object thought connection_from_url 
without timeout. so i patched requests/adapters.py and now work
---------------------------------------------
 del conn = self.get_connection(request.url, proxies)
 add conn = self.get_connection(request.url, proxies, timeout) 
 del def get_connection(self, url, proxies=None):
 add def get_connection(self, url, proxies=None, timeout=None):
 del       proxy_manager = self.proxy_manager_for(proxy)
 add       proxy_manager = self.proxy_manager_for(proxy,timeout)

i am sorry i am not familiar markdown


 

Closed due to inactivity.
Add a comment about lowercase env. variables precedence over uppercase

As suggested by @sigmavirus24 for the follow-up of issue #4579 

Sure @nateprewitt that's updated!

It also looks like we have a windows failure in the tests but it seems like it may be related to a dependency or pipenv issue. Not really relevant for a comment change but something we’ll want to fix.

Let's keep it concise then @nateprewitt 👍 

Thanks @ZuZud! Kicking the tests really quickly to verify this is an actual issue with 3.4 and not transient.

Thanks @ZuZuD!