Raibek/requests-github-issues huggingface dataset:
Fixes: TestSuperLen class

Pytest itself would fail, until I fixed the semantics of the pytest params in the decorator for `test_io_streams`. I am not certain unittests are being used currently, as many tests failed prior to changing anything. Am I not using them correctly?

I also wanted to start a discussion and share thoughts on default_ports, I believe it should be written in the same manner as default_headers.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4944   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4944?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/sessions.py](https://codecov.io/gh/requests/requests/pull/4944/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `76.76% <50%> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4944?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/4944?src=pr&el=footer). Last update [64bde65...41e92c4](https://codecov.io/gh/requests/requests/pull/4944?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@sigmavirus24 Can you provide more information?

Closed due to no feedback.
Leakage of results from one request to another while using session

Hi,
I was facing this issue when using the requests session in gevent workers threads. (https://github.com/ArangoDB-Community/pyArango/issues/65).
I faced the same issue when using Celery (which was not using the gevent for workers) while communicating to the db.
I have changed the code such that for every call to the db a new session is created and issue seemed to be resolved.
I think the issue may be due to large number of concurrent calls to db using the same session.

Regards,
Dilip Vamsi.

As far as I can tell, `requests.Session` is not thread safe, see https://github.com/kennethreitz/requests/issues/2766. So creating a new session per thread is probably the way to go?

@sethmlarson is this issue resolved? Per your comment in https://github.com/psf/requests/issues/2766#issuecomment-2119324917 it seems you didn't think any threading issues remain.

@holmanb that seems an uncharitable read of Seth's statement which is that the issue had become stale and there needed to be new evidence of a threading problem to justify further investigation. I think this issue can also be closed though as stale.
Remove sudo: from .travis.yml

TravisCI has migrated their infrastructure: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration

Test failures seem unrelated and are happening on `master` as well.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4940?src=pr&el=h1) Report
> Merging [#4940](https://codecov.io/gh/requests/requests/pull/4940?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/67a9ed47aec4f9f8280e58e4e05e3a753f62ae15?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/4940/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4940?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4940   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4940?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/4940?src=pr&el=footer). Last update [67a9ed4...334be4d](https://codecov.io/gh/requests/requests/pull/4940?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
request memory leak with no session 

I  use requests lib to monitor  live room。In the start, i use request.get()  and set  connection headers closed, it occured memory leak,  the memory  would increase 10M per 15~20 minutes and dont down. 

Because of live room,  it will created 2000w requests per day. i think maybe there exists some requests dont close,  but i set the connection header closed. Why is it still existed  produced?

In the last, i use request.Session() and keep-alive connection header to solve the problem.   i want to know why   request.get  is bad but session is normal.   

There is my code demo

``` python
while  true:
        headers = {'Connection': 'closed'}
        requests.get(url, headers=headers):
        # when the live room is closed
        if close:
            break
```

``` python
session  =requests.Session()
while  true:
        headers = {'Connection': 'keep-alive'}
        session.get(url, headers=headers):
        # when the live room is closed
        if close:
           session.close()
            break
```

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).

> 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).

This is my request info。I  use python3.6.2,  mac os 10.14.2 
```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.2.2"
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.2"
  },
  "platform": {
    "release": "18.2.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "1010008f",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.19.1"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.23"
  },
  "using_pyopenssl": true
}

```
Make requests compliant with PEP 476

Enables loading of certificate bundles from SSL_CERT_FILE or
SSL_CERT_DIR as mentioned in https://legacy.python.org/dev/peps/pep-0476/

Current patch keeps backwards compatibility by preferring the more
specific options and using the new ones only as fallbacks.

Fixes: #2899

@Lukasa Shouldn't this already have been on master via https://github.com/requests/requests/pull/2903?

Could it be due to this? https://github.com/requests/requests/commit/85a29f1da0d0ccd79e865a7172ea39a2a7667312

@ofek this was merged into the Proposed/3.0.0 branch which isn’t merged with master yet. I’m inclined to uphold the decision Lukasa made the last time this PR was proposed. We’ll treat this as a breaking change because it does have a high probability to break existing setups.

Thanks for the proposal @ssbarnea!

Will work REQUESTS_CA_BUNDLE with capath until than too?
parse_dict_header should return CaseInsensitiveDict

https://github.com/requests/requests/blob/c501ec986daa4961cd9dee370b5d45ff2e524b37/requests/utils.py#L344-L375

In `parse_dict_header` a regular dict is used, but as stated in the RFC the keys should be case-insensitive.

This isn't really part of our public API and it's not meant for parsing into a headers dictionary. This is working as intended for the purpose it is supporting.
certificate verify failed for developers.google.com & api.github.com 

Summary.
    I'm seeing certificate verify failed error on calls to developers.google.com & api.github.com, But calls to aws.amazon.com & azure.microsoft.com are working fine. 

## Expected Result

I'm expecting successful TLS handshake with public domains google and github etc

## Actual Result

Got this exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/urllib3/contrib/pyopenssl.py", line 453, in wrap_socket
    cnx.do_handshake()
  File "/usr/local/lib/python3.7/site-packages/OpenSSL/SSL.py", line 1907, in do_handshake
    self._raise_ssl_error(self._ssl, result)
  File "/usr/local/lib/python3.7/site-packages/OpenSSL/SSL.py", line 1639, in _raise_ssl_error
    _raise_current_error()
  File "/usr/local/lib/python3.7/site-packages/OpenSSL/_util.py", line 54, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.SSL.Error: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]

## Reproduction Steps

```python
import requests
requests.get('https://aws.amazon.com/')
requests.get('https://api.github.com/users/caspyin')
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.4.2"
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.2"
  },
  "platform": {
    "release": "18.2.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "101000af",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.21.0"
  },
  "system_ssl": {
    "version": "1000211f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "using_pyopenssl": true
}
```
```
Python 3.7.2 (default, Dec 27 2018, 07:35:06)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.__version__
'2.21.0'
>>> import certifi
>>> certifi.__version__
'2018.11.29'
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2q  20 Nov 2018'

```

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).

I figured it out. google is failing because of an internal proxy.
remove duplicate import


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

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

```diff
@@            Coverage Diff             @@
##           master    #4929      +/-   ##
==========================================
+ Coverage   66.89%   66.94%   +0.04%     
==========================================
  Files          15       15              
  Lines        1577     1576       -1     
==========================================
  Hits         1055     1055              
+ Misses        522      521       -1
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4929?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/sessions.py](https://codecov.io/gh/requests/requests/pull/4929/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `77.03% <ø> (+0.27%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4929?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/4929?src=pr&el=footer). Last update [5c1f72e...06bd141](https://codecov.io/gh/requests/requests/pull/4929?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@dyq666 can you please update your branch

@inishchith done

tried to re-open to retrigger a build, but can't :(
file named "requests.py" throws AttributeError: module 'requests' has no attribute 'get'

I was playing with requests for a while and I was running into issues

I had a file named requests.py which I was always getting the error:

``` AttributeError: module 'requests' has no attribute 'get' ```

but as soon as I changed the name of the file the error doesn't happen anymore.

Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.

> Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.

How's that a request of help at any matter? I am just pointing a possible bug, which is the fact that the code won't work if I have a file named 'requests.py'.

Never asked for help. Cheers.

If you do `print(requests.__file__)` you will notice, that the Python import machinery loaded your `requests.py` file instead of the `requests` library. So this is in fact not a bug.

> I was playing with requests for a while and I was running into issues
> 
> I had a file named requests.py which I was always getting the error:
> 
> `AttributeError: module 'requests' has no attribute 'get'`
> 
> but as soon as I changed the name of the file the error doesn't happen anymore.

How to change it
return self._store[key.lower()][1] KeyError: 'content-length'

I cannot seem to **constantly** reproduce this bug entirely but, sometimes the header 'content-length' is not present 🤔 whereas, other times it is.
Am I doing something wrong myself?

## Expected Result
The header 'content-length' to be present.

## Actual Result
```
  File "/Users/db/github/Wallie/utils.py", line 18, in download_image
    total_size = int(resp.headers["content-length"])
  File "/Users/db/.local/share/virtualenvs/Wallie-iUwYi7jQ/lib/python3.7/site-packages/requests/structures.py", line 52, in __getitem__
    return self._store[key.lower()][1]
KeyError: 'content-length'
```
## Reproduction Steps

```python
import requests
url = "https://images.unsplash.com/photo-1507608869274-d3177c8bb4c7?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&cs=srgb&ixid=eyJhcHBfaWQiOjQ2NTE2fQ" 
with requests.get(image_url, stream=True) as resp:
        if ((resp.status_code) == (requests.codes.ok)):
            total_size = resp.headers["content-length"]
```

## System Information
    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.1"
  },
  "platform": {
    "release": "18.2.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.21.0"
  },
  "system_ssl": {
    "version": "1000211f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "using_pyopenssl": false
}
```

> I cannot seem to constantly reproduce this bug entirely but, sometimes the header 'content-length' is not present 

It's entirely likely that the content you're retrieving is behind a CDN. In one case, the CDN has it cached and you've hit the cache and so it provides a `Content-Length`, and in the other it's a cache miss so it streams it to you with `Transfer-Encoding: chunked` which means there is no `Content-Length` header. 

>  Am I doing something wrong myself?

In using Requests, no. In understanding how you may receive data, a little. You're not guaranteed nor should you rely on always having a `Content-Length` header. In reality, many headers are optional or mutually exclusive. For example, in this case, it's entirely likely that when there is no `Content-Length` header you're receiving a `Transfer-Encoding` header with the value of `chunked`. In this case you'll want to do something like:


```py
is_chunked = resp.headers.get('transfer-encoding', '') == 'chunked'
content_length_s = resp.headers.get('content-length')
if not is_chunked and content_length_s.isdigit():
    content_length = int(content_length_s)
else:
    content_length = None
```

Cool! Thank you for the explaination! @sigmavirus24
Include Python Information with default User Agent

- A lot of people use default user agent with requests
- Lets include Python runtime + version information
- Allows servers to know some more useful information about their users e.g. PyPI / Warehouse

This will help pypistats.org for example - https://github.com/crflynn/pypistats.org/issues/13

Open to other ideas here. Just throwing this up to start the discussion.

- https://github.com/requests/requests/pull/709
- https://github.com/requests/requests/pull/2803
- https://github.com/requests/requests/issues/2785
- https://github.com/requests/requests/issues/3182

In short, we used to include that and now don't. And we won't be adding it back in any time soon
Remove unnecessary compat shim for OrderedDict

The shim is the same on both Python 2 & 3. It is always `collections.OrderedDict`. Avoid the indirection and import from Python stdlib instead.

Hey @jdufresne, thanks for putting this together. We originally had this change in the commits to remove Python 2.6, but there are at least a handful of well known projects that use Requests compat imports directly.

In order to maintain backwards compatibility, we went ahead and left these intact in Requests 2.x (at least for now) and removed them in the Requests 3.x branch. I think I’d still bias towards keeping them unless there’s a compelling reason they need to go.

Thanks. That makes a lot of sense.

What do you think about keeping the compat shim, but not using it internally? That would avoid the unnecessary indirection internally, but keep the compat import for backwards compatibility. I could also add a comment to explain why it exists so others understand it isn't an oversight.

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

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

```diff
@@            Coverage Diff             @@
##           master    #4922      +/-   ##
==========================================
- Coverage   66.89%   66.81%   -0.09%     
==========================================
  Files          15       15              
  Lines        1577     1579       +2     
==========================================
  Hits         1055     1055              
- Misses        522      524       +2
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4922?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/sessions.py](https://codecov.io/gh/requests/requests/pull/4922/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `76.49% <0%> (-0.27%)` | :arrow_down: |
| [requests/structures.py](https://codecov.io/gh/requests/requests/pull/4922/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc3RydWN0dXJlcy5weQ==) | `52.5% <0%> (-1.35%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4922?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/4922?src=pr&el=footer). Last update [5c1f72e...2aab9a9](https://codecov.io/gh/requests/requests/pull/4922?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Sure, I think that sounds reasonable.
Wrong originating IP address with 2.21

Summary.

In a pod running on a Kubernetes cluster, a python app using `requests`.
When I look the `nginx-ingress` container logs 

With requests <= 2.20.1: the originating IP address of the requests belongs to the **cluster IP range** (which I think is correct)

With requests == 2.21: requests are coming from the **Node pool IP range** (which I don't think is correct)



## Expected Result

Requests should be coming from the cluster IP range

## Actual Result

Requests should be coming from the node pool IP range

## Reproduction Steps

Set up a K8S cluster, a deployment using `requests` and observe logs in the `nginx-ingress` controller pod

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.7"
  },
  "platform": {
    "release": "4.4.111+",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.20.0"
  },
  "system_ssl": {
    "version": "1010006f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "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).


We don't pick our own source IP. I'm surprised that there's a difference between the versions. I think we need a smaller reproduction case because there's just too many moving pieces here.
iter_content() checks for < 1 chunk_size

With requests v2.20.1, supplying a value of 0 for `chunk_size` causes `iter_content()` to hang. This made debugging code that dynamically computes a value for `chunk_size` difficult. These two lines explicitly enforce `chunk_size` being a positive integer.

Hi @alex-wenzel, thanks for taking a look at this. I believe this is actually a duplicate of #4876. This is a new behaviour introduced with the last release of urllib3 where 0 no longer denotes "any size". I believe this is probably a bug since it doesn't make sense to iterate in chunks of 0.

In regards to the PR, I don't think we want to handle the issue with an exception. We handle 0 correctly in `iter_slices` and preventing that would further break the API expectations. We'll track next steps in #4876 for now.

/cc @sethmlarson

@nateprewitt That makes sense, thanks for the quick review/reply!

I'll investigate, thanks for the report. 

What I'm seeing so far is that urllib3 hasn't (in recent history, tested urllib3 1.18 to 1.24.1) not-blocked indefinitely when using `amt=0` into `HTTPResponse.stream()`. Is this issue different from the one described into #4876 which appears to be about `amt=None`?

@sethmlarson after a closer look, it is not. `None` does appear to work correctly with all of the combinations I tried today. It looks like Requests has never supported this actually, at least not since 2.0.

@alex-wenzel I'm going to reopen this since I agree we can do a better job here. Part of me would be more inclined to treat 0 the same way we treat `None`. That would require special-casing logic for `0`->`None` but the alternative of requiring everyone implement this themselves (`len('')`-> `None`) seems silly. The case of `amt<0` is already handled by the standard library. @sigmavirus24, @sethmlarson, any thoughts on that?

What do other streaming interfaces typically do with a chunk size of zero? Any examples in the stdlib? I'd be inclined to copy whatever is done there. 

For what it's worth, the code I was debugging includes:

```python
file_size = int(r.headers['Content-Length'])
chunk_size = int(file_size / 50)
```

...so files smaller than 50 bytes would hang forever. I have to imagine this would be one of the most common reasons a user would inadvertently set `chunk_size=0` and in this case I think having it behave like `None` would be reasonable.

Also, slightly tangential to this thread, but it looks like my most recent changes failed in AppVeyor with an `ImportError` in Python 3.7 specifically that doesn't look related to my changes.

I took a look at getting this added into 2.27.0 but it has some unfortunate side effects. Non-streamed requests currently succeed at returning data from `iter_content` for non-positive integers. While I agree that's nonsensical, adding this behavior breaks that workflow, which we won't be able to do in a minor release.

For the time being, this is an unfortunate behavior which we could definitely document for `iter_content`. We won't be able to merge this PR until it's reworked to maintain current behavior though. Unfortunately, I don't see an immediate way to do that.
Updated wording for switch devhelp

Adding file location for devhelp switch in make.bat

# [Codecov](https://codecov.io/gh/requests/requests/pull/4919?src=pr&el=h1) Report
> Merging [#4919](https://codecov.io/gh/requests/requests/pull/4919?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/5c1f72e80a7d7ac129631ea5b0c34c7876bc6ed7?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/4919/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4919?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4919   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4919?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/4919?src=pr&el=footer). Last update [5c1f72e...be78b20](https://codecov.io/gh/requests/requests/pull/4919?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Thank you, but this file is auto-generated and not manually maintained.
Use 'dist: xenial' in Travis to simplify configuration

Allows using Python version 3.7 without sudo declarations.

Travis officially added support for Xenial on 2018-11-08.

https://blog.travis-ci.com/2018-11-08-xenial-release

Can remove unused Python 2.6 check.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4918?src=pr&el=h1) Report
> Merging [#4918](https://codecov.io/gh/requests/requests/pull/4918?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/5c1f72e80a7d7ac129631ea5b0c34c7876bc6ed7?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/4918/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4918?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4918   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4918?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/4918?src=pr&el=footer). Last update [5c1f72e...06652c1](https://codecov.io/gh/requests/requests/pull/4918?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Remove unnecessary compat shim for bytes

Both Python 2.7 & Python 3 have the type `bytes`. On Python 2.7, it is an alias of `str`, same as what was defined in `compat.py`.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4917?src=pr&el=h1) Report
> Merging [#4917](https://codecov.io/gh/requests/requests/pull/4917?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/5c1f72e80a7d7ac129631ea5b0c34c7876bc6ed7?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/4917/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4917?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4917   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```


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

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4917?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/4917?src=pr&el=footer). Last update [5c1f72e...93cd9cb](https://codecov.io/gh/requests/requests/pull/4917?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


people rely on this code. it's cruft from our 2.5/2.6 days.

Even if the import in `compat.py` sticks around for backwards compatibility, there is no reason to use the non-standard `bytes` internally. Same reasoning as applied in #4922.
possible memory leak 

It seems that my code memory used is increase slowly,I find that even the simplest code will lead this.

## Expected Result
memory won't slowly increase
## Actual Result
memory is slowly increase, running after one hour
![_15456276853678](https://user-images.githubusercontent.com/12421352/50391984-2c7dd680-0785-11e9-9d68-f69823654145.png)
![_15456315045182](https://user-images.githubusercontent.com/12421352/50391986-2e479a00-0785-11e9-8c3d-a6f2792ec8a4.png)

## Reproduction Steps

```python
import requests
def f():
    while 1:
        s = requests.get('https://www.baidu.com')
        text = s.text

if __name__ == '__main__':
    f()
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.3.1"
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.6"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "1010009f",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.19.1"
  },
  "system_ssl": {
    "version": "100020ff"
  },
  "urllib3": {
    "version": "1.23"
  },
  "using_pyopenssl": true
}

```


Seems to be a similar issue : https://github.com/requests/requests/issues/4934

Duplicate of #4934
Normalize percent-encoded bytes before comparison

urllib3 replaced it's URL parser with `rfc3986` for more compliant parsing (urllib3/urllib3#1487). We've also got an effort underway to run downstream tests before releases (urllib3/urllib3#1508) and during that process we've discovered that requests requires percent-encoded bytes to keep their casing.

Adding this to the unit tests would allow either version of pre- and post-rfc3986 urllib3 to pass requests unit tests. I don't know if the `Request.url` attribute needs to maintain it's casing in this situation or not, if it does this is not the solution. Just putting this together as a potential solution.

# [Codecov](https://codecov.io/gh/requests/requests/pull/4915?src=pr&el=h1) Report
> Merging [#4915](https://codecov.io/gh/requests/requests/pull/4915?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/f37daf25006a4b475b1bea90fecdd035146dbc3b?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/4915/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4915?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4915   +/-   ##
=======================================
  Coverage   66.89%   66.89%           
=======================================
  Files          15       15           
  Lines        1577     1577           
=======================================
  Hits         1055     1055           
  Misses        522      522
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4915?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/4915?src=pr&el=footer). Last update [f37daf2...2820839](https://codecov.io/gh/requests/requests/pull/4915?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Closing and re-opening to trigger a new build

Is a newer pytest version not compatible with one of our plugins / our test setup somehow?

Beats me

I guess I'll have to poke around with this more and see why we're getting these funky errors on test load.

Just as I suspected, pytest 4.1 is the problem. Had to deal with this in multiple places at work as well. :( Now to figure out why [Python 3.6 is still installing pytest 4.1.1 despite being locked to `<4.1`](https://travis-ci.org/requests/requests/jobs/481793727#L499).

...and it's installing on Python 3.7 on AppVeyor? Is this a bug with Pipenv and `--skip-lock`?

I don't know what you think about this @sigmavirus24 / @kennethreitz, I don't want to remove the `--skip-lock` because we're getting really outdated dependencies but it looks like `pipenv` is having trouble with the version specifier?

Thanks for merging this!
Turning off keep-alive

In older versions of Requests there was option to turn off keep alive. Something like this:
```
s = requests.session()
s.config['keep_alive'] = False
```
How to do it in recent versions?

Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.

The question asked is not answered https://stackoverflow.com/questions/53870767/turning-off-keep-alive

A similar question with 16 upvoted answers doesn't work for requests 2.x
https://stackoverflow.com/questions/21008953/python-requests-1-how-to-disable-keep-alive

    s = requests.session()
    s.keep_alive = False

    AttributeError: 'Session' object has no attribute 'keep_alive'
Incorrect claim that params go in the request body

c008bf38836a2b5621ba7b352e9fcecacac4ee93 introduced a factual error in to the documentation for the `params` parameter.

The old text was

>  :param params: (optional) Dictionary or bytes to be sent **in the query string** for the :class:`Request`. 

which was replaced by

>  :param params: (optional) Dictionary, list of tuples or bytes to send **in the body** of the :class:`Request`. 

Bold emphasis mine. Obviously `params` still go in the query parameter, no functionality was changed. This was probably a copy and paste error following 2d1b4482c5916433a642d66c6b3d0cd28058b39e.

Please replace *body* with *query string*.

Cc: @moy 


Hi @mjpieters, #4910 addressed this so it should be resolved shortly. Thanks!

Bah, should have checked for pull requests too. Sorry!
Address CVE-2018-20060

Summary.

[CVE-2018-20060](https://nvd.nist.gov/vuln/detail/CVE-2018-20060) identifies a vulnerability in `urllib3` before version 1.23.
 
This project `Pipfile` --> `Pipfile.lock` is using version 1.22 currently: [here](https://github.com/requests/requests/blob/c452e3b92d65cb9b5377606488888da0da5db3ad/Pipfile.lock#L56)

Hi @tuck1s, we reviewed the urllib3 issue when it was disclosed. Requests doesn’t use urllib3’s redirect functionality and we’ve already patched a sinusale vulnerability in #4718.

Good to know, thanks. This came to my attention because Github are sending out warning notices by email, like this, for transitive dependencies. I assume it's likely other folks will also get this warning.

> Known high severity security vulnerability detected in urllib3 < 1.23 defined in Pipfile.lock.
> Pipfile.lock update suggested: urllib3 ~> 1.23.
please help  requests

Please refer to our [Stack Overflow tag](https://stackoverflow.com/questions/tagged/python-requests) for guidance.


code:


import requests
import json
import chardet

email = ("fdff.aaaaaw2@mail.ru ")
payload ={'tk':email,'mk':'2762716611'
         , 'button': 'submit'}

headers = {'user-agent': 'my-app/0.0.1'}
cookies = dict(cookies_are='working')
urlData = ('https://token-seshu.tk/')
webURL = requests.get(urlData, headers=headers,json=payload ,cookies=cookies,allow_redirects=True)
data = webURL
print(json.loads(data.content.decode('utf-8')))



================================================
please help

error


Traceback (most recent call last):
  File "C:/Users/mayar/Desktop/ghf jf.py", line 14, in <module>
    print(json.loads(data.content.decode('utf-8')))
  File "C:\Python34\lib\json\__init__.py", line 318, in loads
    return _default_decoder.decode(s)
  File "C:\Python34\lib\json\decoder.py", line 343, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "C:\Python34\lib\json\decoder.py", line 361, in raw_decode
    raise ValueError(errmsg("Expecting value", s, err.value)) from None
ValueError: Expecting value: line 1 column 1 (char 0)

Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.
@PranayWankhede, the issue being discussed in #3683 was resolved in 2.12.2. As stated in that issue, Requests has no intent to support URIs with underscores in hostnames because those are expressly prohibited in the URI RFC.

If you’re still experiencing this issue prior to 2.12, it’s likely another issue because we did not use idna to validate hostnames at that point. We’d need a concrete example to do anymore debugging here. I’m going to close this for now since this seems like a usage inquiry for unsupported behavior. If you have a use case that’s causing this with a URI that conforms to spec, please feel free to reopen. Thanks!

_Originally posted by @nateprewitt in https://github.com/requests/requests/issues/4904#issuecomment-445982947_
InvalidURL: URL has an invalid label. 

I am getting the following exception for the URL which has underscore in it. After going through https://github.com/requests/requests/issues/3683 I got to know that this issue is only for the request library version >= 2.12. But i encountered similar issue for 2.11.1. Are there any changes to the older versions? Thanks!
 

@PranayWankhede, the issue being discussed in #3683 was resolved in 2.12.2. As stated in that issue, Requests has no intent to support URIs with underscores in hostnames because those are expressly prohibited in the URI RFC.

If you’re still experiencing this issue prior to 2.12, it’s likely another issue because we did not use idna to validate hostnames at that point. We’d need a concrete example to do anymore debugging here. I’m going to close this for now since this seems like a usage inquiry for unsupported behavior. If you have a use case that’s causing this with a URI that conforms to spec, please feel free to reopen. Thanks!
SSL handshake Error when using chunked uploads via Proxy

When attempting to perform a chunked upload by passing a generator to put() as the data argument, while going through a proxy server (either unauthenticated or with basic auth), a ConnectionError is raised with the content of `("bad hanshake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",)`. Connecting without proxy, and connecting via proxy with other libraries (pycurl), works as expected. I've verified the failure still occurs with the latest requests release. Proxy server in testing is Squid 3.5.20.

## Expected Result

Successful connection.

## Actual Result

ConnectionError

## Reproduction Steps

```python
import requests

def file_read(fileobj):
    while True:
        data = fileobj.read(1024 * 1024 * 4)
        if not data:
            break
        yield data


proxy_string = 'http://proxy.server:8080'
session = requests.Session()
session.proxies = {'http': proxy_string, 'https': proxy_string}
headers = {
    'Content-Type': 'application/octet-stream',
    'x-amz-acl': 'bucket-owner-full-control',
}
with open('/tmp/some-large-file', 'rb') as f:
    url = 'https://aws.bucket/path/to/some-large-file'
    requests.put(url, data=file_read(f), headers=headers)
```

## System Information

Python 2.7.13 with requests 2.18.4 (though reproduced with 2.20.1 on same system), in virtualenv, connecting via Squid 3.5.20 proxy server with either basic auth, or no authentication.


Python 2.7.3 is ancient, and has numerous bugs fixed in 2.7.5 that make it unsuitable for usage with Requests. Please use a later version of 2.7 or even a version of python 3.

Sorry, that was a typo. It's 2.7.13. Please re-open.

@sigmavirus24 Can you please re-open this It is with 2.7.13, not .3. Thanks.

Please provide us with the output of

```
python -m requests.help
```

We'll need more details before we can reopen this as an investigation of a bug. This seems more likely to be a problem with your proxy config from my experience, though.

```
~$: python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": "2.0.3"
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.13"
  }, 
  "platform": {
    "release": "3.13.0-160-generic", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "1010006f", 
    "version": "17.2.0"
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "1000106f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": true
}
```

Can this please be re-opened, as the requested information had been provided? Thanks.
Only use urllib3's pyOpenSSL support when SNI isn't available

I'm floating this idea because currently our native `ssl` module support isn't being utilized by any requests users and I'm planning on making major improvements to SNI within native `ssl` support in urllib3 including leaning on the stdlib for hostname verification.  What are the thoughts on only using pyOpenSSL when `urllib3.util.HAS_SNI` is false?

That would be potentially backwards incompatible. At this point, we inject pyOpenSSL when it's there. It was primarily for SNI support, but I believe this enables other things the stdlib doesn't support and that some users may be relying on "if pyOpenSSL is installed, requests uses it" at this point.

Ah okay, I was unaware there were extras besides SNI being added. Thanks for the clarification!
Not clear how to build coverage report

I was looking into trying out mutation testing (with mutmut) on requests, seeing as this is one of the most critical libraries for python. But to do this effectively I need to get the coverage report and this was non-trivial.

## Expected Result

`tox -e coverage` or `make coverage` should run tests with coverage.

## Actual Result

It complains about me not having pipenv, so I installed that, then it build some venv and then fails with

```
pipenv run py.test --cov-config .coveragerc --verbose --cov-report term --cov-report xml --cov=requests tests
Error: the command py.test could not be found within PATH or Pipfile's [scripts].
make: *** [coverage] Error 1
```

(aside: py.test? It's pytest nowadays)

## Reproduction Steps

Check out requests. Run `make coverage`.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.7"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.15"
  }, 
  "platform": {
    "release": "18.0.0", 
    "system": "Darwin"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.20.1"
  }, 
  "system_ssl": {
    "version": "1000210f"
  }, 
  "urllib3": {
    "version": "1.24.1"
  }, 
  "using_pyopenssl": false
}
```



Hi @boxed,

There's a couple options for running coverage.

1.) You'll need to setup pipenv to run `make coverage`. More info on that [here](https://pipenv.readthedocs.io/en/latest/).
2.) You can call `pytest --cov-config .coveragerc --verbose --cov-report term --cov-report xml --cov=requests tests` directly with the pytest dependencies installed. You can find those dependencies in the [Pipfile](https://github.com/requests/requests/blob/master/Pipfile).

Why did you close this? This is a documentation and/or tooling issue, not a support forum question.

This is the first report of someone who couldn't get the tooling to work. If it continues to be an issue, we can invest time in figuring out how to make it easier. Otherwise, I agree with Nate closing this.
Exceptions occur when nonstandard headers are returned

requests==2.20.1
python2.7.15
 ```
HTTP/1.1 200 OK
	Content-Type: application/octet-stream
	Content-Length: 35239
	Content-Disposition: attachment; filename="text.txt" 
```


Exceptions occur when tabs exist in HTTP return headers
Exception information: `Header continuation with no previous header: urllib3.exceptions.InvalidHeader: Header continuation with no previous header: 	Content-Type: application/octet-stream
`

It's not that these are non-standard headers. It's that the headers are formatted as if they're all part of the line `HTTP/1.1 200 OK`. This is a bug that has been opened in the past. It's not something we can fix. There's only so much we can do to override httplib's behaviour when a server completely and totally misbehaves.