Raibek/requests-github-issues huggingface dataset:
revert azure pipeline changes

Since we don't have access to the new testing infrastructure, we're going to revert the Azure changes for now. We can revisit this once the permissions issues are fixed.

Reverting commits:
fc9dfac
bc3eddc
d911f27
3da2f10
ce52825
398d110
c15d2b6
086655e

For auditing purposes, I missed e4974c7 in this commit and it's been reverted in abe950c.
Library IDNA 2.7 and 2.8

Summary.

Since off the grid I manually installed IDNA 2.8 as a dependant.  When installing requests via the .whl file v2.20.1 version.  It manually tried to download the IDNA 2.7 version.  I manually installed IDNA 2.7 and the install completed correctly.

What you expected.

To install correctly with IDNA 2.8

What happened instead.

When installing Requests version IDNA 2.7 will be downloaded.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.1"
  },
  "platform": {
    "release": "2008ServerR2",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.20.1"
  },
  "system_ssl": {
    "version": "1010009f"
  },
  "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).


Duplicate of #4890 

In the future, please search **closed and** open issues before creating new ones that are duplicates.
idna 2.8 released

[`idna`](https://pypi.org/project/idna/#history) 2.8 was just released. requests is [pinned to `idna>=2.5,<2.8`](https://github.com/requests/requests/blob/57d7284c1a245cf9fbcecb594f50471d86e879f7/setup.py#L46)

Can the pin be updated to allow v2.8?

By the way, out of curiosity, what's the reason to pin minor version number at all?
It seems it was first introduced in 1ea27b35649571abb796f7cffbab83938d882a8d, but there is no explanation in the commit metadata.

@Vlad-Shcherbina why have a lowest version we support? Because that's the lowest version we know works with idna at all. Libraries change things in subtly backwards incompatible ways. If we don't put together a range of known good versions, users will use whatever they want, shoot themselves in the foot, and demand we fix it for them. With only 2 people working on this project, no one has time for that

My 2 cents.

`aiohttp` library depends on `yarl`. In turn, `yarl` depends on `idna>=2.0`.
So far so good.
`aiohttp` uses `twine check` for making sure that `setup.py` is (at least partially) correct.
There is no surprise that `twine` uses the awesome `requests` (almost every tool that needs synchronous HTTP access uses `requests`).

Today our daily CI job has failed wit version conflict error. Sure, we can create a separate virtual env for  `twine` usage or we can find another solution but the situation looks odd.

On another hand I understand the striving to pin everything for such community important project: any backward incompatibility in `requests` dependencies can hurt too many people.

Could you please make a new release? 
Releasing `requests==2.20.2` should not take too long perhaps.

>  Releasing requests==2.20.2 should not take too long perhaps.

Changing version constraints would lead to a 2.21 version. There's already a PR for upgrading the dependency version https://github.com/requests/requests/pull/4889

Breaks py-requests, and in turn certbot under MacPorts.

Hi @Schamschula, we’re aware of the impact. Using the requirements specified by Requests will continue to work until the next patch is released. I’m aiming to get something out early next week once we can get the testing issues worked out.

@nateprewitt Thanks for the update.!

 In the meantime, I've opened a ticket for those MacPorts users that might run into this issue:

https://trac.macports.org/ticket/57747

Requests 2.21.0 is up on PyPi now supporting idna 2.8.
Bumped maximum version of idna


AppVeyor failures don't seem related to this patch

Failing vsts build also looks unrelated to this patch.

@alex The build will fail for Python 3.5 on `idna==2.8` so I think the bump isn't safe. I just saw the same at work

I'm not sure I understand? Why do you think this will fail with Python 3.5? AFAICT, idna did not drop support for it: https://github.com/kjd/idna/commit/2618ad17c86498d627ebb136143c2799ad48cbe3

We're using 3.5 (where also failed) and the [request-ci](https://kennethreitz.visualstudio.com/requests/_build/results?buildId=17) in this PR failed for the same version (just checked it was for Windows, tho). I'm also not sure about why. Maybe it's a coincidence and I misunderstood the log 

Hey @alex, thanks for getting this put together. I agree the failures look unrelated. Kenneth recently changed our testing infrastructure and I don’t think we’ve validated it’s working since. I’ll take a look at things this evening and try to work out the issue.

So it looks like this is just a spurious pipenv failure. I've disabled appveyor but I don't seem to have any permissions for Azure. @kennethreitz do we have a way to get Ian and I access to the build infrastructure?

Why not `<3` ? Pinning a maximum minor version causes install fails of `requests` whenever a new minor version of `idna` is released, even if that version is compatible. Instead, you could allow _any_ version of idna v2, and then there will only be issues with `requests` if there are incompatibilities in `idna`.

@jakul we can't guarantee future compatibility with a library whose backwards compatibility we don't manage. It often occurs that people break things accidentally. That's all fine until someone upgrades their version they use with requests to find requests is broken and then we get 50 bug reports within 30 minutes of the release telling us we're broken. Most people don't immediately need the latest version of idna, they tend to use the overly eager upgrade strategy in pip meaning that they get it, think they need it, and pester us to upgrade. That's fine, because we can then fix the incompatibility when we find it, meanwhile users can restrict themselves to using the version compatible with everything.

@sigmavirus24 Thanks for taking the time to write a detailed response. I understand your points, but I think it's a tradeoff between "the requests team have to do work everytime idna makes any release" vs "the requests team have to do work if idna does a release which actually breaks something in requests". 

That's my 2 cents, cheers.

Yes, but that's a tradeoff we're willing to make. "Stability in the requests user experience because we can proactively fix an accidental backwards incompatibility" versus "This is an arcane instability happening in 2% of our users cases that we could have caught and now people don't trust requests to be stable because we promised forwards compatibility that we couldn't actually guarantee."

Alright we've got successful builds, so I'm going to rebase and merge. Thanks Alex!

https://ci.appveyor.com/project/kennethreitz/requests/builds/20888463
windows for ubuntu18.04,data={"id":None},no response

Summary.

## Actual Result

No response, no timeout parameter does not work

## Reproduction Steps

```python
import requests

url = "https://dt-dev.arctron.cn/api/zone/get"    (my company progect)
data = {"id":None}
headers = header
reqs = requests.post(url=url,data=data,headers=header)
```
## the picture
![image](https://user-images.githubusercontent.com/42604280/49431871-5cbb0080-f7e9-11e8-946f-ec1cb82b0982.png)





Seems to be an issue with the host: `https://dt-dev.arctron.cn/api/zone/get`

`curl https://dt-dev.arctron.cn/api/zone/get` acts the same.
https://docs.python-requests.org certificate's CN is *.readthedocs.org

This is not a software bug but a deployment bug.
http://docs.python-requests.org does not redirect to HTTPS.
In some browsers, visiting https://docs.python-requests.org, will give SSL_ERROR_BAD_CERT_DOMAIN, because the certificate's CN does not match the requested URL.
https://readthedocs.org/projects/requests/latest/ redirects http://docs.python-requests.org.

## Expected Result

docs.python-requests.org Website via HTTPS

## Actual Result

SSL_ERROR_BAD_CERT_DOMAIN: Unable to communicate securely with peer: requested domain name does not match the server’s certificate. 

## Reproduction Steps

Open https://docs.python-requests.org in a browser, or:
```
curl https://docs.python-requests.org
curl: (51) SSL: no alternative certificate subject name matches target host name 'docs.python-requests.org'
```

currently unsupported
raise requests.exceptions.ReadTimeout for streaming responses

Currently, if there is a read timeout while streaming a response, a `requests.exceptions.ConnectionError` is raised in lieu of a `requests.exceptions.ReadTimeout`. This is unexpected and [contrary to the documentation](http://docs.python-requests.org/en/latest/user/quickstart/#timeouts).  As a user, I am being forced to catch the `ConnectionError` when I only actually care about the `ReadTimeout` situation.

This PR revises the streaming response code to properly raise a `requests.exceptions.ReadTimeout`, consistent with [the non-streaming request behavior](https://github.com/requests/requests/blob/57d7284c1a245cf9fbcecb594f50471d86e879f7/requests/adapters.py#L528). 

I am unable to write a test for this situation since `httpbin` does not support a delay for chunked-encoded responses; see requests/httpbin#479 regarding this lack of functionality.

Any thoughts on this? I think this is clearly a bug in the existing implementation...... is there something I am missing?

ping anyone want to take a look at this?

I looks like this has been fixed in the 3.0 branch, and the comments on #2392 and #5430 note that a change like this is too much of a breaking change to ship with 2.x. So maybe this should be closed? (With an explanation for people encountering the issue, please!)

FWIW, though, I got here because I only recently had time to really dig into Requests and Urllib3 to understand what was happening here — this has been a longstanding issue in a codebase I maintain, where we were successfully catching some read timeouts but not others. I definitely understand I don’t speak for all users, but, like @VasiliPupkin256, having this fix in 2.x would not break me and would actually really help me clean up some messy code by making error handling more consistent (I currently catch both `Timeout` and `ConnectionError`, but for the latter case inspect the error string to decide what to do, which is really not good).
`requests.utils.guess_json_utf` breaks on Python 3

Unable to use `Response.json()`. I notice `requests.utils.guess_json_utf` expects type str but then breaks at `sample.count(_null)`, understandably because `<str>.count(<bytes)` is not valid - [see the function here](https://github.com/requests/requests/blob/57d7284c1a245cf9fbcecb594f50471d86e879f7/requests/utils.py#L851-L886).

## Expected Result
```In [10]: from requests.models import Response

In [11]: response_dict = {'foo':'bar'}

In [12]: response = Response()

In [13]: response.status_code = 200

In [14]: response._content = json.dumps(response_dict)

In [15]: response.json()
'{'foo': 'bar'}'
```
## Actual Result
```
In [10]: from requests.models import Response

In [11]: response_dict = {'foo':'bar'}

In [12]: response = Response()

In [13]: response.status_code = 200

In [14]: response._content = json.dumps(response_dict)

In [15]: response.json()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-15-670418389d1b> in <module>()
----> 1 response.json()

/data/virtualenv/py3default/lib/python3.6/site-packages/requests/models.py in json(self, **kwargs)
    882             # decoding fails, fall back to `self.text` (using chardet to make
    883             # a best guess).
--> 884             encoding = guess_json_utf(self.content)
    885             if encoding is not None:
    886                 try:

/data/virtualenv/py3default/lib/python3.6/site-packages/requests/utils.py in guess_json_utf(data)
    868     if sample[:2] in (codecs.BOM_UTF16_LE, codecs.BOM_UTF16_BE):
    869         return 'utf-16'     # BOM included
--> 870     nullcount = sample.count(_null)
    871     if nullcount == 0:
    872         return 'utf-8'

TypeError: must be str, not bytes
```

## Reproduction Steps
Follow the steps in Actual Result

## System Information
```
(py3default) deploy@lemon:/data/shared/buffet/bokchoy/tests$ 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": "4.4.0-51-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010009f",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.19.1"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.23"
  },
  "using_pyopenssl": true
}
(py3default) deploy@lemon:/data/shared/buffet/bokchoy/tests$ python --version
Python 3.6.6
```

Possibly related to: https://github.com/requests/requests/issues/4879

Yep, this is a dupe of #4879. We’ll track there.
Use a certificate

I'm trying to use a certificate with requests. I need to use a certificate to access internal services at work. I have installed it on chrome per example to access some internal sites.

With curl I can use it that way: `curl -s --cacert /home/path/certificate.crt -u USER:PASSWORD https://server:8443/teste`

With requests I can't make it work. I have already read some old closed issues without success. I also created a post on stack-overflow but I couldn't understand the answers I got on comments. https://stackoverflow.com/questions/53340465/cant-use-a-crt-certificate

I use the command 
`r = requests.get('https://server:8443/teste', auth=HTTPBasicAuth('USER', 'PASSWORD'), verify='/home/path/certificate.crt')`
 with result:
`requests.exceptions.SSLError: HTTPSConnectionPool(host='server', port=8443): Max retries exceeded with url: /teste (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)'),))`

Thank you

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, thank you. I tried to get help there without success :(
Make a seperate repo for requests3.


Why?

Indeed, why? I thought it would be easier to keep things in a single place (at least from a user PoV).

Is it https://github.com/kennethreitz/requests3?

it is indeed! It's a different namespace, and a different package.

https://github.com/kennethreitz/requests3

It would be better to create requests2, should someone need that, and drop python 2 support. Things that depend on the name requests can pin to an old version.
Cryptiles dependency vulnerability: Update to >4.1.2

Hello!

In some of the Microsoft Bot Framework repos have a dependency on request which has an indirect dependency on Cryptiles. We are getting a warning from a security vulnerability that would be solved upgrading cryptyles to >4.1.2. 

It seems like it is an indirect dependency of yours. Any idea how I can fix this vulnerability or plans to somehow upgrade cryptiles dependency?

Thanks!

Hi @carlosscastro, we shouldn’t have any dependencies on that package. Can you tell us how you determined this was tied back to Requests?

I took a look and that is a JavaScript package. Requests only contains python code, so I think this may be filed in the wrong repository. Perhaps you were looking for the request/request repo.
SSLError(SSLError(0, 'unknown error (_ssl.c:3517)

I am trying to invoke a api which is sitting in a load balancer server. The server uses certificate chain which i downloaded from browser in .p7b file and passing in my code 
`r=request.get(uri,headers=header,verify='certificate.p7b').`
 Even I tried generating .pem file through openssl commands, but it didn't work. I also tried using "verify=False" sttement. But getting the same error:
Please help.

Hi @JeetBhattachariya, this is an exception in _ssl.c on line 3517. That's code within CPython, so without an exact version of your interpreter and likely a dummy cert that we can reproduce this with, it's going to be very difficult to debug.

We can take a closer look if you can provide all of the information you originally requested, but this appears to be a cert or standard library issue. [StackOverflow](https://www.stackoverflow.com) is probably a better venue for that though since this doesn't appear to be an issue with Requests code base. I'm going to close this for now, but feel free to add a link to the StackOverflow question if you choose to create one.
Add Python 3.7 to tox test matrix


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

```diff
@@           Coverage Diff           @@
##           master    #4868   +/-   ##
=======================================
  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/4868?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/4868?src=pr&el=footer). Last update [bedd928...779fd6e](https://codecov.io/gh/requests/requests/pull/4868?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Simplify tox.ini

Tox installs the package to the virtualenv by default. PySocks is
already included in test_requirements. Don't need to install these
explicitly.

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

```diff
@@           Coverage Diff           @@
##           master    #4867   +/-   ##
=======================================
  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/4867?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/4867?src=pr&el=footer). Last update [bedd928...af63554](https://codecov.io/gh/requests/requests/pull/4867?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Changes to improve intelligibility

I believe that it was not cleat, what the modified snippet referred to

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

```diff
@@           Coverage Diff           @@
##           master    #4865   +/-   ##
=======================================
  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/4865?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/4865?src=pr&el=footer). Last update [6cfbe1a...9aa876a](https://codecov.io/gh/requests/requests/pull/4865?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
why use Session post a data contain a empty tuple,the status_code always 400

Summary.
why use Session post a data contain a empty tuple,the status_code always 400

## Expected Result
200
200
## Actual Result
200
400

What happened instead.

## Reproduction Steps

```python
#-*- coding:utf8 -*-
import requests

if __name__=='__main__':
    session = requests.session()
    params={}
    a=()
    params.update({'id':a})
    httpresult = session.get('http://www.baidu.com/',data=params)
    print httpresult.status_code
    httpresult = session.get('http://www.baidu.com/')
    print httpresult.status_code

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.12"
  }, 
  "platform": {
    "release": "4.15.0-29-generic", 
    "system": "Linux"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.20.0"
  }, 
  "system_ssl": {
    "version": "1000207f"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": false
}
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).


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.
Redirect double encoding

This change makes requests more tolerant of a misconfigured Apache server that escapes percent signs in its redirects.  The change includes tests that fail without the change and pass with the change.

Hi @behanna, thanks for putting the time and effort into creating this patch! While we want Requests to be tolerant of common server misbehaviors, this seems be a pretty niche case. We provide the option in Requests to disable redirects with the `allow_redirects` flag for cases when users need to handle special redirect circumstances. I'd say that's probably the better approach in this case since we'd otherwise be adding somewhat magic behavior here that may not apply to all users.
Set iter_lines() decode_unicode default to False

The docs just read a bit strange with `decode_unicode=None` as opposed to `False`.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4861   +/-   ##
=======================================
  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/4861?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/models.py](https://codecov.io/gh/requests/requests/pull/4861/diff?src=pr&el=tree#diff-cmVxdWVzdHMvbW9kZWxzLnB5) | `77.35% <0%> (ø)` | :arrow_up: |

------

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


I had a suspicion that it was meaningful but it appears it isn't from a cursory look. Go ahead

Thanks again @altendky! ✨
PyPI page for requests shows raw markup

https://pypi.org/project/requests/ shows raw markdown.

## Expected Result

Properly formatted text.

## Actual Result

![ekrano nuotrauka is 2018-11-05 17-19-29](https://user-images.githubusercontent.com/159967/48006834-fde96500-e11e-11e8-9173-69de1ab7ca73.png)

## Reproduction Steps

Open https://pypi.org/p/requests in a browser


Hi @mgedmin, this is a result of the version of twine used to upload the 2.20 release. The readme was recently changed to markdown which had issues rendering properly with older versions of twine.

We’ll be doing a hotfix release sometime this week which will resolve the issue. Thanks for making sure we were aware :)
HTTPConnectionPool(host='207.45.249.157', port=80): Max retries exceeded with url: http://www.google.com/ (Caused by ProxyError('Cannot connect to proxy.', NewConnectionError('<urllib3.connection.HTTPConnection object at 0x00000234AC984898>: Failed to establish a new connection: [WinError 10060]

Hi, I'm working on a python project, I use python3 with anaconda

I'm trying to execute a simple get request with this code:

import requests

proxies = {'http' : 'http://207.45.249.157',
                'https': 'https://207.45.249.157'}

r = requests.get('http://www.google.com/', proxies=proxies)

and I get this error as a result:

ProxyError: HTTPConnectionPool(host='207.45.249.157', port=80): Max retries exceeded with url: http://www.google.com/ (Caused by ProxyError('Cannot connect to proxy.', NewConnectionError('<urllib3.connection.HTTPConnection object at 0x00000234AC984898>: Failed to establish a new connection: [WinError 10060]')))

I'm quite new to python, especialy to the requests module

Thanks

Hi @ImARegularUser, welcome to the world of Python! The issue you’re seeing here is with your proxy rather than Requests. I’d suggest reviewing the [proxy docs](
http://docs.python-requests.org/en/master/user/advanced/#proxies) and debugging from there. For future reference, we prefer usage questions to be directed towards StackOverflow with the python-requests tag since this issue tracker is reserved for defects in Requests. Thanks!

Alright, Thanks for you reply and sorry for the mistake x)
Remove unnecessary travis config

Each job already defines its `script`, so need 
to define it at the top level.

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

```diff
@@           Coverage Diff           @@
##           master    #4856   +/-   ##
=======================================
  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/4856?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/4856?src=pr&el=footer). Last update [c501ec9...5e0fbae](https://codecov.io/gh/requests/requests/pull/4856?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Not sure why this was closed. Is there anything I should fix up?

Also, I just noticed that `sudo:` should be removed. TravisCI has migrated to the new infrastructure already: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration . It's also not necessary on [xenial for Python 3.7](https://github.com/deadsnakes/travis-ci-python3.7-example#update-2018-07-03)
Fix the syntax highlighting of README


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

```diff
@@           Coverage Diff           @@
##           master    #4855   +/-   ##
=======================================
  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/4855?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/4855?src=pr&el=footer). Last update [eaab47f...1de5d47](https://codecov.io/gh/requests/requests/pull/4855?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Hi @frostming, I believe these classes are defined for specific formatting by @kennethreitz. I'm going to err on the side of caution and pass on these for now since the current readme is valid markdown. If Kenneth has different thoughts, I'll defer to him to reopen and merge this.

Thanks for the suggestion!
respect_retry_after_header in urllib3.util.retry.Retry is not respected

## Summary

I am trying to setup backoff and retry for 429 errors in a module I'm working on.

I want to ignore any `Retry-After` headers that are returned by the target API. According to the requests/urllib3 documentation I've followed, the code below should work, but instead of my backoff the full `3600` seconds set in the response to `http://httpstat.us/429` (which I'm testing against) is being used for the sleep.

## Reproduction Steps

```python
import logging

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

logging.basicConfig(level=logging.DEBUG)

session = requests.Session()
retries = Retry(
    total=3,
    backoff_factor=0.3,
    status_forcelist=[429],
    raise_on_status=False,
    respect_retry_after_header=False
)
session.mount('https://', HTTPAdapter(max_retries=retries))
session.mount('http://', HTTPAdapter(max_retries=retries))

resp = session.get('http://httpstat.us/429', timeout=5)
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.7"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.10"
  }, 
  "platform": {
    "release": "18.0.0", 
    "system": "Darwin"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.20.0"
  }, 
  "system_ssl": {
    "version": "20000000"
  }, 
  "urllib3": {
    "version": "1.24"
  }, 
  "using_pyopenssl": false
}
```


Add 


Closed due to inactivity.
Incorrect ValueError Message on ~requests.utils.from_key_val_list comments

The function `requests.utils.from_key_val_list` raises ValueError with message `cannot encode objects that are not 2-tuples`.
On the function comments it show that it  raises ValueError with message `need more than 1 value to unpack`

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

```diff
@@           Coverage Diff           @@
##           master    #4853   +/-   ##
=======================================
  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/4853?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/4853?src=pr&el=footer). Last update [eaab47f...045b706](https://codecov.io/gh/requests/requests/pull/4853?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
proper handling for default ports in auth stripping

This is an attempt to address the default port issues presented in #4850. Our recent changes around auth stripping to handle downgrade attacks in #4718 broke compatibility for cases like http://example.com:80 -> http://example.com. This will allow the use of "default" ports and no port interchangeably.

If you get a moment @sigmavirus24, I'd like a second pair of eyes on this. I'm not ecstatic about continuing to expand this function, but I don't think there's an easier simplification of what we have.

@nateprewitt  : hi nate. version bump not required? 

@rishabh5j, this will be in the next release, likely 2.20.1.

@nateprewitt  : thanks i can see its version upped now.
Authorization header dropped accidentally because wrong port change detection logic

Summary.

## Expected Result

We have a library code using requests, when we get a URL with auth, it will be redirected to cas authentication url which is exactly same schema, same hostname, but for the port, our original request explicitly gave 443, but the location returned in 302 response is without ":443" (means default 443 https), in such case we expect the redirected request should not strip the authorization header. 

## Actual Result

The authorization header is stripped and causing eventually 401 error. 

## Reproduction Steps

```python
import requests
session = requests.Session()
session.auth = ('admin', 'password1')
response = session.get('https://example.com:443/foo')
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.7"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.5"
  },
  "platform": {
    "release": "4.15.0-36-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.20.0"
  },
  "system_ssl": {
    "version": "1010008f"
  },
  "urllib3": {
    "version": "1.24"
  },
  "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).


Hi @quickwind, thanks for bringing this to our attention. I've quickly tossed together #4851 to address the problem. I'm not ecstatic about the solution, but it should resolve the issues. I'll try to give the issue some more thought in the morning and we'll work towards getting this resolved in the next bugfix release.

@nateprewitt Thanks for your quick response, looking forward to next patch version...

No problem @quickwind, we'll likely wait another week to see if anything else crops up and then I'll look at getting a hotfix release out. Going to close now that #4851 is merged.
Extending Gitignore for Easier Contribution

`.gitignore` has been changed.

# Rationale
Developers/contributors might use different tools. These tools might provide undesired files about tests, test reports, binary files et cetera. That's why `.gitignore` had to be updated.

# What has changed?
Old entries are still present at the end of file so that maintainers can still have the same result. The file was generated by [gitignore.io](https://www.gitignore.io). A full path to what aspects have been included can be seen in the first line of `.gitignore` file. Anyway, to be verbose:

 - **Jetbrains + Pycharm** caches, configs etc.
 - Generic **Python** files which are not supposed to be in the repository such as archived sources, compiled `pyc` files etc. This section also contains some files for `pytest`, `coverage` and `tox`.
 - **Virtualenv** has been extended. Other developers/tools might use different path for virtualenv. Pycharm default is `.venv` while current gitignore does not have that, instead, it has `env/` entry.

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

```diff
@@           Coverage Diff           @@
##           master    #4849   +/-   ##
=======================================
  Coverage   66.79%   66.79%           
=======================================
  Files          15       15           
  Lines        1572     1572           
=======================================
  Hits         1050     1050           
  Misses        522      522
```



------

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


Users of these various tools should use [a global gitignore](https://help.github.com/articles/ignoring-files/#create-a-global-gitignore).
Option for retrieving peer's TLS certificate

It would be good to have an option to retrieve the peer's TLS certificate after a request is performed. For example, this is what libcurl provides with [CURLINFO_CERTINFO](https://curl.haxx.se/libcurl/c/CURLINFO_CERTINFO.html).

There's a StackOverflow thread which offers some rather ugly methods to do this: https://stackoverflow.com/questions/16903528/how-to-get-response-ssl-certificate-from-requests-in-python

I actually managed to fix this via an adapter, but would like for this to be natively supported. Also, TLS certificate is fetched prior a connection is fully established, as the certificate is checked for validity and only then "fully" connected.

Requests actually fetches the certificate at some pint, but it does not allow it to be stored saved somewhere, which might further complicate in situations where TLS pinning is needed.
Adding `timeout` changes behavior without raising an exception

I am using `requests` to query a website.
If I query with `timeout`, it behaves like I want (well, kind of).
If I query without `timeout`, the request hangs.

This behavior seems to be specific to this website. My code works fine against other websites.

## Expected Result

The request does not hang.

## Actual Result

Without `timeout`, the request hangs.
With `timeout`, the request takes the full timeout window before returning successfully.

## Reproduction Steps

```python
#!/usr/bin/env python3

import requests

# Works -- but takes the full timeout before the call returns
print('Try 1')
r = requests.get('https://repo.packagist.org/p/jrodella/payment-form-api.json', timeout=5)

# Hangs
print('Try 2')
r = requests.get('https://repo.packagist.org/p/jrodella/payment-form-api.json')
```

If I add in logging, the hang occurs after the log statement:

```
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): repo.packagist.org
```

## System Information

    $ python -m requests.help

```
(13:21:07) jamie@woody ~/Desktop/EcosystemRegexps/ecosystems $ python3 -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "1.9"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.2"
  },
  "platform": {
    "release": "4.15.0-33-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1000207f",
    "version": "17.3.0"
  },
  "requests": {
    "version": "2.18.1"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.21.1"
  },
  "using_pyopenssl": true
}
```

Hi @davisjam,

This is the expected behavior of not passing a timeout, the connection will remain open until closed by one of the involved parties.

This information is available at the top of the timeout section in the [docs](http://docs.python-requests.org/en/master/user/quickstart/#timeouts).

>  Nearly all production code should use this parameter in nearly all requests. Failure to do so can cause your program to hang indefinitely

Hi @nateprewitt.

I have read the documentation. Perhaps I was too hasty in my writeup.

Can you clarify what I find the odd behavior here? Namely that:

> With timeout, the request takes the full timeout window before returning successfully.

This implies that there is a path wherein the timeout expires but no exception is raised.
I could not find this described in the documentation.

If I add `verify=False` then no `timeout` parameter is necessary; the request completes promptly and the website closes the connection.
About the json param

In my work, I encountered such a problem:
Developers require the use of most compact json.
But when I use the requests module, 
I found that the internal code used "body = complexjson.dumps (json)".
This is not flexible enough.
Especially when developers do not deal with such problems. (I am a tester)
So, can you add a parameter to deal with this kind of thing?
Looking forward to your reply.

Developers can already use their own JSON serialization by not using the `json` parameter. We will not add a new parameter to a feature-frozen API for an unspecified use-case.