Raibek/requests-github-issues huggingface dataset:
Fix docs for data param in api

The data param also accepts a list of tuples. It says so in the docs for request() but not for post(), put() and patch()

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

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

```diff
@@            Coverage Diff             @@
##           master    #4331      +/-   ##
==========================================
+ Coverage      89%   90.08%   +1.07%     
==========================================
  Files          18       15       -3     
  Lines        2065     1543     -522     
==========================================
- Hits         1838     1390     -448     
+ Misses        227      153      -74
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4331?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/api.py](https://codecov.io/gh/requests/requests/pull/4331/diff?src=pr&el=tree#diff-cmVxdWVzdHMvYXBpLnB5) | `81.81% <ø> (ø)` | :arrow_up: |
| [tests/testserver/\_\_init\_\_.py](https://codecov.io/gh/requests/requests/pull/4331/diff?src=pr&el=tree#diff-dGVzdHMvdGVzdHNlcnZlci9fX2luaXRfXy5weQ==) | | |
| [requests/utils.py](https://codecov.io/gh/requests/requests/pull/4331/diff?src=pr&el=tree#diff-cmVxdWVzdHMvdXRpbHMucHk=) | | |
| [requests/compat.py](https://codecov.io/gh/requests/requests/pull/4331/diff?src=pr&el=tree#diff-cmVxdWVzdHMvY29tcGF0LnB5) | | |

------

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


this is unnecessary information.
Question: How to throttle bandwidth of a given REST call

I'm transitively using Requests, by using [locustio](https://github.com/locustio/locust).

Basically, we're loadtesting a service that accepts file-uploads (pretty much just a vanilla POST request). We want to slow down the upload to resemble what a real user's bandwidth would look like. (For clarification, the machine that runs the test is high-powered to replicate a large number of users. This, however, has the trade off that a large file upload that a user normally performs takes seconds instead of minutes; which falsely tests the application we're hitting).

We're looking at systemically slowing the bandwidth of the machine itself to replicate what a user would see, but we want to know: is it possible to do this programmatically?

There is nothing built into requests to do this. Depending on how you're trying to upload files you can either implement a generator that sleeps the appropriate amount of time or a file-like object that sleeps the appropriate amount of time.

In the future, please ask questions on [StackOverflow](https://stackoverflow.com).

@sigmavirus24 Thank you, and will do
Python 3.7 is supported

The README says "Requests officially supports Python 2.6–2.7 & 3.3–3.7, and runs great on PyPy." so update the version in some other places too.

Should we instead remove 3.7 from the README and the commented out 3.7-dev from .travis.yml?

Alternatively: the commit message for the commenting out was to speed up the build: https://github.com/requests/requests/commit/2758b8b0f029abb9166eb1f124dcabe1bd35e949

Travis gives up to five parallel build jobs, but only four are taken per build. Should 3.7-dev be re-enabled?

Having said that, there's still 8 months until 3.7 release, so I think the best thing to do is not claim support yet, but if possible test it. See https://snarky.ca/how-to-use-your-project-travis-to-help-test-python-itself/

See https://github.com/requests/requests/pull/4341 to remove claimed support from the README.

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

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

```diff
@@            Coverage Diff             @@
##           master    #4329      +/-   ##
==========================================
+ Coverage   88.28%   88.66%   +0.38%     
==========================================
  Files          18       18              
  Lines        2031     2021      -10     
==========================================
- Hits         1793     1792       -1     
+ Misses        238      229       -9
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4329?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [tests/testserver/\_\_init\_\_.py](https://codecov.io/gh/requests/requests/pull/4329?src=pr&el=tree#diff-dGVzdHMvdGVzdHNlcnZlci9fX2luaXRfXy5weQ==) | `86% <0%> (+12.66%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4329?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/4329?src=pr&el=footer). Last update [8c4f784...ed1ccf6](https://codecov.io/gh/requests/requests/pull/4329?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Remove redundant Python 2.6 stuff

Python 2.6 support was dropped in https://github.com/requests/requests/pull/4118.

This removes some other redundant 2.6 code. 

Also mention Python 3.7 as officially supported, to reflect the README.


Looks like some failures regarding cookies, could you check those out?

Similar cookie failures are happening on latest master:

https://travis-ci.org/requests/requests/builds/279556831

You're right, those will have to be fixed in a different PR. I'm :+1: from my brief look at these changes.

Hey @hugovk, thanks for taking the time to put this PR together! Unfortunately it's pointed against our master branch rather than our proposed/3.0.0 branch where the original #4118 was made. It appears some of this is redundant but there are also new changes. If you'd like to move those over to a PR against the correct branch, we'd be happy to review them. Thanks again for you work!

@nateprewitt Thanks, I've created https://github.com/requests/requests/pull/4328 against proposed/3.0.0.

But don't you want this stuff in master as well? Or do you have another process for merging 3.0.0 back into master at some point? 

I guess you don't want to support 2.6 in releases after 3.0.0 either :)

@hugovk, yes, we'll be merging the 3.0.0 branch back into master when we're ready to release. Until that time though, we're not planning on removing 2.6 support so these need to stay out of the master branch to allow future releases in the 2.x series.
Session adapter doesn't update https connections cert data

Under a session, the first https request sets the HTTPSConnectionPool certs data.
If in a subsequent request, we change the certs data (eg: Set verify to True), the adaptor will update the ConnectionPool attributes, however each connection in the pool will still contain the old certs data, thus when requesting a connection from the pool, its info will differ from what we would expect.

## Expected Result

The used connection should have updated certs data

## Actual Result

The used connection have "old" certs data.

## Reproduction Steps
These tests where performed against a server with a self-signed CA.
```python
In [1]: from requests import Session

In [2]: url = "https://somepage"

In [3]: auth = ("admin", "admin123")

In [4]: s = Session()

In [5]: s.get(url, auth=auth, verify=False)

Out[5]: <Response [200]>

# This should fail, but doesnt
In [6]: s.get(url, auth=auth, verify=True)

Out[6]: <Response [200]>

# Create a new session
In [7]: Session().get(url, auth=auth, verify=True)
# Raises certificate verify failed
```
I'm aware ConnectionPool is in urllib realm, but since it's the adaptor who is updating the pool data, perhaps it should also handle this scenario?
## System Information

{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": "1.7.2"
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.12"
  }, 
  "platform": {
    "release": "4.4.0-59-generic", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "1000207f", 
    "version": "16.0.0"
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "1000207f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": true
}

Yeah. Requests is using some old APIs in urllib3 that don’t interact with the connection pooling. It should update to pass the TLS data into the pool manager to ensure that the TLS info factors in. 

@Lukasa thanks for your prompt reply

This is also true of the certificate/key paths provided in the `cert` keyword argument. It seems that the `certfile` and `keyfile` attributes are maintained on the connection and not reset if a new `cert` kwarg is given on a subsequent request on the session.

Still observing this in 2.21.0, but you can issue session.close() to clear out the poolmanager, which will allow new requests with different verify values to be paid attention to.
Reuse ssl.SSLContext across all SSL connections within a requests.Sesssion

requests should pass `ssl_context` to `urllib3.PoolManager`: https://github.com/requests/requests/blob/2a4dd64fb4c072c646277c9d057737b05351b86f/requests/adapters.py#L161-L162

Otherwise a new SSLContext is allocated for all requests. SSLContexsts can be huge, like 1MB, so doing this will be a performance and memory usage win.

It looks like Requests doesn't define `ssl_context` anywhere. Where should it be created?

How is the status of this issue?

Hello, me and my group mates are going to be working on this issue.

@alex Could you tell me where you have an instance of ssl_context within the code? Thank you.

This should be largely addressed in 9a40d1277807f0a4f26c9a37eea8ec90faa8aadc.
SSL Proxy Support

When accessing HTTPS urls via an NTLM proxy, the get request fails with a request.exceptions.ProxyError

I believe this is because the hook to use requests-ntlm isn't dispatched when performing the SSL tunnel. That is, a socket error is thrown when I get a 407 in httplib._tunnel().

Are there any plans to support https queries using a proxy auth extension?

## Expected Result

HTTPS NTLM requests should authenticate on the proxy and get the external site.

## Actual Result

A request.exceptions.ProxyError is thrown

## Reproduction Steps

```python
import requests
from requests_ntlm import HttpNtlmAuth

session = requests.Session()
session.auth = HttpNtlmAuth(user, pass)
session.proxies = {'http': 'http://ntlm-proxy:8080', 'https': 'http://ntlm-proxy:8080'}
resp = session.get('https://httpbin.org/get')

# resp.status_code should = 200, however received 407
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.9"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.6"
  },
  "platform": {
    "release": "2008ServerR2",
    "system": "Windows",
  },
  "pyOpenSSL": {
    "openssl_version": "1010006f",
    "version": "17.0.0"
  },
  "requests": {
    "version": "2.17.3"
  },
  "system_ssl": {
    "version": "90819f"
  },
  "urllib3": {
    "version": "1.21.1"
  },
  "using_pyopenssl": true
}
```


Requests-NTLM is a separate project from Requests: please raise this issue on that repository. 

Sure - I think this may involve both projects though. 

The exception is thrown within sessions.py:
```python
# Send the request
r = adapter.send(request, **kwargs)
```

Within send(), the SSL tunnel is attempted - and reaches down into httplib._tunnel()
```python
def _tunnel(self):
    ...
    response = self.response_class(self.sock, strict = self.strict, method = self._method)
    (version, code, message) = response._read_status()
    
    if code != 200:
        self.close()
        raise socket.error("Tunnel connection failed: %d %s" % (code, message.strip)))
```
We would need the 407 handled here to handle custom authentication.
I think it would be an issue with ntlm, kerberos, etc, etc. tunnelling.


As a general rule no Requests sub-project handles authing on TLS tunnelling. This is ultimately because httplib simply doesn’t give us appropriate hooks to do so. 🙁

Yeh makes sense thanks @Lukasa . I'll take a look at monkeypatching or using pycurl instead. :-(

Does urllib3 v2 still have momentum?

Due to my job change it has less momentum than it did before. Hopefully I'll find some quiet time to take more of a run at it, or we'll decide to land it as-is.
netrc reading does not respect NETRC environment variable

As described [here](https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html), there is an environment variable `NETRC` which one can use to control where `.netrc` file is. Requests always searches in user's home directory.

## System Information

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.2"
  },
  "platform": {
    "release": "14.5.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020cf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

Do we still want this feature? I want this feature, but I don't know overall sentiment among users.

I see that https://github.com/psf/requests/pull/4339 was closed because it wasn't finished. I volunteer to finish the work with appropriate test coverage and documentation.

This has been open very long without response. How will this case be handled? This would be a very good feature to implement.

This project has generally had a terrible experience with it's netrc support. It causes confusion and isn't convenient to disable. If anything, I'd expect the current maintainers to want to drop support for finding/parsing netrc files and close this as something they won't implement. (And they'd be right to do so)

Awesome! Thanks!
Avoid importing platform

platform module is relatively large: it takes about 5ms to import.

Is `sys.platform` always equal to `win32` even on 64bit windows installations?

Might wanna do `sys.platform.startswith('win')`? I've seen that in another library, can't recall which.

It is always 'win32'.
https://docs.python.org/3/library/sys.html#sys.platform

https://github.com/python/cpython/blob/d6bb65f378e34fe0c11fdb39588357ecf22964eb/PC/pyconfig.h#L297-L301

Once https://github.com/kennethreitz/httpbin/pull/392 merges and Kevin releases a pytest-httpbin package, the tests here should start passing.

@methane would you mind rebasing this onto the current master branch?

done

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

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

```diff
@@           Coverage Diff           @@
##           master    #4316   +/-   ##
=======================================
  Coverage   88.28%   88.28%           
=======================================
  Files          18       18           
  Lines        2031     2031           
=======================================
  Hits         1793     1793           
  Misses        238      238
```


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

------

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


:tada: LGTM
In reponse, jQuery****({...});

Summary.

## Expected Result
I expected to return this form.

{"success":true,"code":"1000",...}

## Actual Result
I return this form with request.get()

jQuery1708155690935019391_1506579003758({"success":true,"code":"1000",...});
## Reproduction Steps

```python
url = 'https://apis.naver.com/commentBox/cbox/web_naver_list_jsonp.json?ticket=news&templateId=default_society&pool=cbox5&_callback=jQuery1708155690935019391_1506579003758&lang=ko&country=&objectId=news032%2C0002793071&categoryId=&pageSize=20&indexSize=10&groupId=&listType=OBJECT&page=1&initialize=true&userType=&useAltSort=true&replyPageSize=20&moveTo=&sort=favorite&includeAllStatus=true&_=1506579003809'

header = {
    "Referer": 'http://www.naver.com' # The referer means my access was from this referer. In this case, referer can be any site from naver
}
res = rq.get(url, headers = header)

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.9"
  },
  "idna": {
    "version": ""
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.2"
  },
  "platform": {
    "release": "4.4.0-51-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "100020bf",
    "version": "17.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020cf"
  },
  "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).

@kimyoungjin06, the endpoint you're hitting seems to be returning exactly what you're asking for, a JSON dataset wrapped in a callback function (`jQuery1708155690935019391_1506579003758`) which you have declared in the URL parameters. You'll receive the same result if you perform this request with another tool like curl.

I'm closing this since it's not a Requests issue.
Connecting from HTTPAdapter: Forbidden: Access is denied

I'm trying to connect with certificate via HTTPAdapter, but the server always returns me error: 403 - Forbidden: Access is denied. This is the code:

```
class DESAdapter (HTTPAdapter):
    def __init __ (self, cert=None, key=None):
    
        self.cert_file = cert
        self.key_file = key
        super (DESAdapter, self) .__ init __ ()

    def init_poolmanager (self, connections, maxsize, block = False):
        self.poolmanager = poolmanager.PoolManager (
            num_pools = connections, maxsize = maxsize,
            block = block,
            cert_file = self.cert_file,
            key_file = self.key_file)

con = requests.Session ()
Adapter = DESAdapter (cert = certi, key = key)
con.mount (self.url, Adapter)
res = con.post ('url', data = 'xml_soap', verify = False, headers = 'header')
```

If you try without `HTTPAdapter()`, as the code below, then it works:

```
res = requests.post ('url', data = 'xml_soap', cert = (cert_path, key_path)
                            verify = False, headers = 'header')
```

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

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.7.1"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.10"
  },
  "platform": {
    "release": "XP",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "100020af",
    "version": "16.2.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000201f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}

Hi,
I am having the same problem with HTTPAdapter.
Forbidden: Access is denied

Hi there! Upon furthur review of this issue, 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.
[bug]request http over https proxy

`python 2.7.13`
`requests v2.18.4`

request http website over https proxy  always failure.

the proxy is checked pass by `http_proxy=https://ip:port  curl ip.sb`

```python
import requests
proxies={'http':'https://proxyhost'}
requests.get('http://targeturl' , proxies=proxies)
```

but request http over https proxy 
```python
import requests
proxies={'https':'https://proxyhost'}
requests.get('https://targeturl' , proxies=proxies)
```

it's ok



Please provide us with the output of 

```
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": "16.5.0", 
    "system": "Darwin"
  }, 
  "pyOpenSSL": {
    "openssl_version": "1010006f", 
    "version": "17.2.0"
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "100020cf"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": true
}

```

Requests does not support HTTPS proxies, so whatever happens here is going to be almost random. 

@Lukasa   So what kind of library can I use to replace it?
SSLError: SOCKSHTTPSConnectionPool(host='www.google.com', port=443)

Open a new issue is to facilitate the view, because   #4272 too long.
maybe it can help other people

we know uses socks5 need install 
`pip install requests[socks]`

when i use
`pip install --upgrade requests[socks]`

```
import reqeusts
proxies = {'http': 'socks5://127.0.0.1:1080', 'https': 'socks5://127.0.0.1:1080'}
r= requests.get(url,proxies=proxies)
```
failed

`SSLError: SOCKSHTTPSConnectionPool(host='www.google.com', port=443)......`

I use 
`pip install -U requests[socks]==2.12.0`

it works,not error infonation.


I meet the same error today. Oddly, the error didn't appear when I setup the same programe tomorrow. 

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

See also https://github.com/requests/requests/issues/4272#issuecomment-345642450, try using `socks5h` instead of `socks5`

This does appear to be related to incorrect use of the socks5 vs socks5h scheme. Since we haven't had a response to the requested information in a few months, I'm closing this out. Please feel free to reopen if you have more information. Thanks!

> See also [#4272 (comment)](https://github.com/psf/requests/issues/4272#issuecomment-345642450), try using `socks5h` instead of `socks5`

wow thanks!
Warn about possible slowness when using an older version of pyOpenSSL

[This](https://github.com/requests/requests/issues/4278#issuecomment-329516221) comment on #4278 suggests warning about possible slowness for older versions of pyOpenSSL.

I'd love to work on this, I'm just not sure which versions to warn about and would love input from some developers more experienced with the library.

So I think @Lukasa or @sigmavirus24 may have a more definitive answer to this, but it looks like `PyOpenSSL 16.0.0` was when the `Cryptography>=1.0` requirement was put in place. From my understanding that's when the speed ups were implemented.

We already require `Cryptography>=1.3.4` in both Requests and urllib3 though, so users entering this state are installing the PyOpenSSL requirement from another package. If we implement a warning, I think we should first check that PyOpenSSL is installed, and then if cryptography's version is less than 1.3.4. 

>so users entering this state are installing the PyOpenSSL requirement from another package. If we implement a warning, I think we should first check that PyOpenSSL is installed

Just to be clear, do you mean check that the OpenSSL module is available, or check specifically that the module is pyOpenSSL?

@PrimordialHelios, I *believe* that PyOpenSSL is sufficient (and much easier to check). We don't import or use cryptography directly in Requests, so the urllib3 pyopenssl contrib module should be our only point of contact.

This should be resolved with #4332 merged. Thanks again @PrimordialHelios!
request.get params change

I use` requests.get` to do some web scraping and one key of params, which shows below, changes strangely. 
Where is the "25" from? Does it come from the sys environment or language set? Thanks ~

## Expected Result

the `r.url` is
```
 'http://www.shufaziti.com/?char=%E7%BA%B5&size=96&forecolor=0&backcolor=0&radio=0'
```
## Actual Result

the `r.url` is 
```
'http://www.shufaziti.com/?char=%25E7%25BA%25B5&size=96&forecolor=0&backcolor=0&radio=0'
```
## Reproduction Steps

```python
import requests
web = "http://www.shufaziti.com/"
key = {"zong":"%E7%BA%B5", "xia":"%E4%B8%8B"}
shkey = {"char": key["zong"], "size": "96", "forecolor": "0",  "backcolor": "0", "radio": "0"}
r = requests.get(web, params=shkey)
```

## System Information
```
Windows10(64-bit)
Python 3.6.2 | Anaconda custom(64-bit)
Requests version: 2.14.2
```

When you specify `params=` we URL encode the parameters to ensure they're safe. You already have them url-encoded, however, so we're urlencoding the `%` signs as `%25` to make them urlsafe. I can't recall if we've changed this behaviour in newer versions (I think we merely ensure we don't encode something we've already encoded) but you can fix this now by unencoding those parameters yourself before passing them to us.

Cheers,
Ian

@sigmavirus24 Thanks, and btw how to unencoding by hand?

@limTeTE google `urlquote` and `unquote` with the version of Python you're using.
urllib3.exceptions.InvalidHeader exception leak

In some cases `urlib3.exceptions.InvalidHeader` exception is not being replaced with `requests.InvalidHeader` and leaks.

## Expected Result

Raise `requests.exceptions.InvalidHeader(RequestException, ValueError)`.

## Actual Result

`urllib3.exceptions.InvalidHeader` is raised.

## Stack trace

```
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 515, in get
return self.request('GET', url, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 502, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 612, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 440, in send
timeout=timeout
File "/usr/lib/python2.7/dist-packages/urllib3/connectionpool.py", line 616, in urlopen
**response_kw)
File "/usr/lib/python2.7/dist-packages/urllib3/response.py", line 467, in from_httplib
**response_kw)
File "/usr/lib/python2.7/dist-packages/urllib3/response.py", line 155, in __init__
self.length_remaining = self._init_length(request_method)
File "/usr/lib/python2.7/dist-packages/urllib3/response.py", line 229, in _init_length
"unmatching values (%s)" % length)
    
exception.type: InvalidHeader
exception.value: Content-Length contained multiple unmatching values (0, 9929)
```

## System Information

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.14"
  },
  "platform": {
    "release": "4.12.0-2-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.1"
  },
  "system_ssl": {
    "version": "1010006f"
  },
  "urllib3": {
    "version": "1.21.1"
  },
  "using_pyopenssl": false
}

Thanks for opening this issue, @piotrjurkiewicz! It does seem like we should try to wrap this in the Requests exception namespace. It looks like the HTTPError funnel in adapters.py raises everything it doesn't recognize [here](https://github.com/requests/requests/blob/5eb0811ef82244afbcd865a19b796a76cdecfd71/requests/adapters.py#L523). There are actually a few newer exceptions from urllib3 I'm not sure we're accounting for in this case.

I'm not positive what the best approach is since we'll end up with an increasingly growing exception conditional list  if urllib3 continues to add more exceptions. Alternatively, we could return a more generic wrapper exception but that'll likely make debugging harder.  I'm sure one of the other maintainers will have a leaning on which direction to go here.

Same here. Recieving an exception in console:

```
urllib3.exceptions.InvalidHeader: Content-Length contained multiple unmatching values (1526, 4578)
```

Resolved in #5914.
Attempting to send struct packed binary data over requests

I attempted to send struct-packed binary data over your lib, failed for me. I placed it in the cookie header, as what im doing requires it to be.

For some strange reason, it said connection refused

This does not seem to be a bug in requests, but instead a question better suited for [StackOverflow](https://stackoverflow.com/questions/tagged/python-requests). Please instead direct this and all future questions there.
Possible to remove some headers?

Would it be possible to remove some headers from a POST request, ie for example connection, Accept-Encoding, Accept */*. Unfortunately, writing an exploit and unable to continue unless these headers have been removed strangely enough.

Requests does not support the removal of arbitrary headers. It is possible to remove *some* by using the [PreparedRequest flow](http://docs.python-requests.org/en/master/user/advanced/#prepared-requests), but this will not cover all headers.
response(200) always need to wait for 120 seconds


i use requests to send a HTTP request like this:
![image](https://user-images.githubusercontent.com/10825713/30731867-746a995c-9fa2-11e7-81d1-5b8ddd6e24bc.png)
and the response like this:
![image](https://user-images.githubusercontent.com/10825713/30731883-866ddd58-9fa2-11e7-90f7-99eea26bd2b8.png)
and i always need to wait for 120s to get the response 

The remote server is sending a HTTP response with no Content-length or Transfer-encoding chunked. This means that the server is saying "the request body is complete when I close the connection". Requests is doing the right thing and waiting for that connection close before it returns. The server should set content-length.
'big5' encoding not detected

See this feed: http://www.digitimes.com.tw/tech/rss/xml/xmlrss_10_0.xml

The top line of the feed is:

    <?xml version="1.0" encoding="big5" ?>

But the detected encoding is iso-8859-1. It should be big5.

## Expected Result

r.encoding should be big5.

## Actual Result

r.encoding is iso-8859-1.

## Reproduction Steps

```python
>>> import requests
>>> r = requests.get('http://www.digitimes.com.tw/tech/rss/xml/xmlrss_10_0.xml')
>>> r.encoding
'ISO-8859-1'
>>> print r.text[900:1000]
xÆW¤Ó¶§¯à¹q¦À¤jÁp·ù¡A´Á¯à¶i¦æ¾ã¦X¡A¥Ø«e±À´ú¬ù¦³4®a¼t°Ó°Ñ»P¡A¥i¯à¥é·Ó¦­´ÁÁp¹q°Æ¸³¨Æªø«Å©ú´¼¥l¶°²Õ¦¨¥x
>>> r.encoding = 'big5'
>>> print r.text[900:1000]
均三緘其口。即將跨入10月PV Taiwan年度展期，近期台太陽能市場熱鬧非凡，除了對模組聯盟最終拍板......]]></description>
<keyword><![CDATA[太陽能矽晶圓
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": "1.6"
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.10"
  }, 
  "platform": {
    "release": "16.7.0", 
    "system": "Darwin"
  }, 
  "pyOpenSSL": {
    "openssl_version": "100020af", 
    "version": "16.2.0"
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "9081df"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": true
}
```

We rely on `chardet` to determine the encoding of the content. Whatever `chardet` library says is what we auto-detect the content as.

Something strange is going on then...

```
>>> import chardet
>>> chardet.__version__
'3.0.4'
>>> import urllib
>>> r = urllib.urlopen("http://www.digitimes.com.tw/tech/rss/xml/xmlrss_10_0.xml").read()
>>> chardet.detect(r)
{'confidence': 0.99, 'language': 'Chinese', 'encoding': 'Big5'}
>>> requests.get('http://www.digitimes.com.tw/tech/rss/xml/xmlrss_10_0.xml').encoding
'ISO-8859-1'
```

I had something similar recently, so I decided to take a look.

The encoding that is selected for this response seems to be coming from `get_encoding_from_headers()` at https://github.com/requests/requests/blob/master/requests/utils.py#L428. Because the digitimes.com.tw's server returns a `Content-Type` with 'text' in its value (`text/xml`), `ISO-8859-1` is assumed.

The detected character set by `chardet` (`apparent_encoding`) is only used when no `encoding` has been set (before parsing the response content body?)

One solution would be to remove the assumption in `get_encoding_from_headers()`, but I don't know what consequences that would have.

This is covered by #2086. However, I should note that there is no way that Requests will ever look into the HTML: only that it will use chardet.
Stop Requests.post from encoding the data field,

Hello,

I was wondering if it it is possible to stop requests from encoding the data field in a post request?

I guess im saying in request body, in a post request.

Yes: just pass a string, not a dictionary. 

You mean data="cmd = blah"

Yes. 

Just did that, getting 
```python
Traceback (most recent call last):
  File "command_php_exec_noauth.py", line 9, in <module>
    req = requests.post("http://{}:{}/command.php".format(args.target, args.port), data="cmd = ls -alt")
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 112, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 490, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
```

Just did that, getting 
```python
Traceback (most recent call last):
  File "command_php_exec_noauth.py", line 9, in <module>
    req = requests.post("http://{}:{}/command.php".format(args.target, args.port), data="cmd = ls -alt")
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 112, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 490, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
```

That means the server is closing the connection in our face. Suggests a problem in the server code. 

Strange, shouldnt be if im essentially able to send the equivalent of this with curl and it works fine.

I take it its not possible to disable URL encoding for the data field?

Only using the method I mentioned.
Still SSLError: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",) after enable 3DES

Summary.
When I use requests to crawl a url ,the cmd always show me bad handshake,and after I refer other solution,it doesn't make sense.The real reason is that the module requests cann't support 3DES

## Expected Result

The requests support 3DES algorithm.
## Actual Result

For the url using 3DES,the requests module cann't work.

## Reproduction Steps

```
import requests
response=requests.get("https://supply.zte.com.cn/UI/Web/Application/kxscm/kxsup_manager/Portal/index.aspx ")```

## System Information
```
   Windows10 python3.6<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).

This is intentional: 3DES is insecure for bulk data transfer, and so we disabled it to help protect our users. You can re-enable it for specific hosts as [shown here](https://lukasa.co.uk/2017/02/Configuring_TLS_With_Requests/).
pipfile (work in progress)

Signed-off-by: Kenneth Reitz <me@kennethreitz.org>

Pipenv has matured a *lot* since we were last using it — I think it's ready for prime time now. 

this looks like it's working great except for 2.6 support — which requests should probably drop anyway. 

excellence! builds are working great :)

will merge once all green, here in a minute. 

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

```diff
@@           Coverage Diff           @@
##           master    #4295   +/-   ##
=======================================
  Coverage   88.66%   88.66%           
=======================================
  Files          18       18           
  Lines        2021     2021           
=======================================
  Hits         1792     1792           
  Misses        229      229
```



------

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


All Green! 💚
Failed to establish a new connection: [Errno 10060]

Summary.

## Expected Result

What you expected.

## Actual Result

What happened instead.

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
 Downloading to: e:\Learning\Powershell\C#vs.Net\udemy-dl-windows-2.1.3\udemy-dl-windows\csharp-tutorial-for-beginners

 Trying to log in ...
 Exception
Traceback (most recent call last):
  File "udemy_dl.py", line 976, in <module>
  File "udemy_dl.py", line 971, in main
  File "udemy_dl.py", line 766, in udemy_dl
  File "udemy_dl.py", line 156, in login
  File "udemy_dl.py", line 143, in get_csrf_token
  File "udemy_dl.py", line 113, in get
  File "site-packages\requests\sessions.py", line 515, in get
  File "site-packages\requests\sessions.py", line 502, in request
  File "site-packages\requests\sessions.py", line 612, in send
  File "site-packages\requests\adapters.py", line 502, in send
ProxyError: HTTPSConnectionPool(host='www.udemy.com', port=443): Max retries exceeded with url: /join/login-popup (Caused by ProxyError('Cannot connect to proxy.', NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x03571850>: Failed to establish a new connection: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond',)))
Failed to execute script udemy_dl

Seems like you're having trouble connecting to your proxy. Without a better idea of what's going on, we can't really help you I'm afraid. ☹️ 

I'm going to close this out due to lack of information and this appearing to be a usability question. If you have more information and feel this is a defect with Requests rather than your environment, we can look at reopening. Thanks!

I have similar issue,
F:\udemy-dl\udemy-dl-windows>udemy-dl.exe https://www.udemy.com/vue-2-crash-course/learn/v4/overview
Username / Email : email@example.com
Password :
 Downloading to: F:\udemy-dl\udemy-dl-windows\vue-2-crash-course

 Trying to log in ...
 Exception
Traceback (most recent call last):
  File "udemy_dl.py", line 976, in <module>
  File "udemy_dl.py", line 971, in main
  File "udemy_dl.py", line 766, in udemy_dl
  File "udemy_dl.py", line 156, in login
  File "udemy_dl.py", line 150, in get_csrf_token
AttributeError: 'NoneType' object has no attribute 'group'
Failed to execute script udemy_dl

Please help. Thanks.

Hi @nyoman, the stacktrace you provided is unrelated to Requests or this issue. I would suggest asking for assistance from the `udemy-dl` maintainers or posting a question on StackOverflow. Thanks!

I meet the same question, I don't know where the trouble is. Please help me!
New HTTPHeaderDict class for response headers with multiple header value support

Same changes as my other pull request #4282, but this against the proposed/3.0.0 branch.

The CI builds are failing on tests which were failing before my changes were pushed (honest!)

We know :)

@Lukasa what do you think of this? I'm very :+1: personally.

I think this will be a major improvement to Requests.

Why reinventing the wheel? `urllib3` has a multiheader-ready headers implementation for ages. Stable, fast, reviewed and well tested. If I remember correctly, it was already suggested a while ago to reuse it also in requests, so that it could be avoided to copy and re-read all the headers, which would also be a considerable speed improvement on creating a Response object.

Merged into '3.0' branch. ✨🍰✨

Pending further modifications.
Bad name in the request: not a legal PLSQL identifer

Hello guys, relatively new to python. Met with this error while trying to use request POST to extra information. Header and data are directly copied and paste from using google chrome when the POST is made. Couldn't identify any wrong with the formData. Am i missing out on something?

> import requests

> formData = {
>     'acadsem':'2017_1',
>     'r_course_yr':'ACC%3BGB%3B2%3BF',
>    ' r_subj_code':'Enter+Keywords+or+Course+Code',
>     'boption':'CLoad',
>     'semester':'1',
>     'acadsem':'2017_1'
>     }
> url = "'www.example.com/"
> 
> response  = requests.post(url, data = formData)
>    
> print(response.content)

You're passing urlencoded form data to our `data` parameter which will in turn urlencode it. You will want to decode `r_course_yr`'s value.

In the future, please use StackOverflow for questions of this type.
redirect(301) always need to wait for 120 seconds

code like this:
import requests
requests.request('get', 'http://10.192.74.230:6201/en?CSnaL/uZkQC9SLVbaMoQDA8Ph9/+Q7+stJc7S1qGSuvEss6zmYfB7SvYE4vAOWgfUrJuxOBk7giWoAKARD9o7oaZlmg84SgIEIvBgnqr3Jj9OH9RPt4MEbQmHmhsDfBfMzY2OA==')

expect return a response with status_code=301 and then will auto send to the new url in "Location" of 301 response.
actually requests.request() will not get a return value until after 120 seconds.and in wireshark log i can see the 301 response received immediatly.



the received 301 message:
HTTP/1.1 301 Moved Permanently
Location: http://10.192.74.193:6801/en?OquUyLHZ2FyZUDNp2IFFPnft8SvIpFbincdfI+28KZTEss6zmYfB7SvYE4vAOWgfUrJuxOBk7giWoAKARD9o7pP2snF7YaLGUe2u5T4m2HKqrfp1J6hXLT424Rl2iJWSNjkwMA==&&act=get&ztype=0&zvalue=100
Connection: close
Date: Tue, 12 Sep 2017 09:15:20 GMT



The 301 is setting `Connection: close`, so we're waiting for it to be closed before we continue. This is because 301s may have bodies, and we need to handle that possibility. There's not much we can do about this: the server should either remove `Connection: close` (because it doesn't seem to need it), or it should close the connection immediately.