Raibek/requests-github-issues huggingface dataset:
status_code return 200 in fact , it's should return 302

Summary.

## Expected Result

status_code return 302

## Actual Result

status_code return 200

## Reproduction Steps

```python
In [17]:  import requests
In [18]: a=requests.get( 'http://spj.anshan.gov.cn/aszwdt/epointzwmhwz/pages/default/legal/wanttodo/')
In [19]: a.status_code
Out[19]: 200
In [20]: a.url
Out[20]: u'http://spj.anshan.gov.cn/aszwdt/epointzwmhwz/pages/default/index;jsessionid=CDF3C67801FB507FBD15B6FC2366244E'

```

## System Information

    
```
{
  "chardet": {
    "version": "3.0.2"
  },
  "cryptography": {
    "version": "1.8.1"
  },
  "idna": {
    "version": ""
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.13"
  },
  "platform": {
    "release": "16.7.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "1010005f",
    "version": "17.0.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020ff"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```
python version:
2.7.14
2.7.5


The 302 status code is in ```a.history``` because requests had already handled the redirect.

See also http://docs.python-requests.org/en/master/user/quickstart/?highlight=redirects#redirection-and-history
docstring inconsistent with requests.api.post

I run the `pytest tests` and find `requests.api.post` receive `data` whose type is `list_iterator`, which is inconsistent with its docstring.

## Expected Result

modify docstring of `requests.api.post` to `:param data: (optional) Dictionary (will be form-encoded), bytes,list_iterator,or file-like object to send in the body of the :class:Request.`

## Actual Result

what the docstring shows.

## Reproduction Steps

the test case is in `requests/tests/test_lowlevel.py::test_chunked_upload`, which `data` is a `iter` and passed to `requests.api.post`.

```python
import requests
def test_chunked_upload():
    """can safely send generators"""
    close_server = threading.Event()
    server = Server.basic_response_server(wait_to_close_event=close_server)
    data = iter([b'a', b'b', b'c'])

    with server as (host, port):
        url = 'http://{0}:{1}/'.format(host, port)
        r = requests.post(url, data=data, stream=True)
        close_server.set()  # release server block

    assert r.status_code == 200
    assert r.request.headers['Transfer-Encoding'] == 'chunked'
```

## System Information

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.2.2"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.5"
  },
  "platform": {
    "release": "17.5.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "1010008f",
    "version": "17.5.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020ef"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```


Hi @YannLuo,

Requests will take an iterable object containing bytes for the data param which is noted in [the documentation](http://docs.python-requests.org/en/master/user/advanced/#chunk-encoded-requests). We could specify in the docstring that bytes iterables work here too, but it's a more verbose explanation than proposed. I'm not sure is necessary given that bytes is specified and the specific case of chunked-encoding is defined in the docs which is what these iterators are used for.

I tend to agree with @nateprewitt 

It looks like we have consensus among the maintainers. It’s likely best to expose this to people specifically looking to use chunked transfer-encoding which the documentation handles. I’m going to close this since there doesn’t appear to be anything actionable, but feel free to let us know if you feel we’re missing something. Thanks!
Default data should be dict, not list

https://github.com/requests/requests/blob/e4fc3539b43416f9e9ba6837d73b1b7392d4b242/requests/models.py#L223

In request class, empty data should be dict, not list.

What makes you think that?

Since we haven’t had a response and the issue is unclear I’m going to close this for now. @kalaomer feel free to reopen this with more information if you feel there’s still an issue.
add HTTP 419 to requests.codes

via status_codes.py.
fixes #4572

Hey @mxmader, thanks for taking the initiative to put this together and start the conversation While there are some uses of 419 on the web, it’s not standardized as you noted in the related issue. I’d personally prefer we avoid introducing things like this (there are a handful of non-standard status codes) into Requests. Primarily because we’ll get follow on PRs asking where the line is for status code x, y, z and if the IETF ever decides to use any of these codes we can’t “unrelease” versions of Requests with bad constants. Since this constant list has no effect on how Requests handles a received 419, I think we’re likely to pass on this. I’ll let @sigmavirus24  weigh in before we close this though.

no problem. this PR was part thought experiment, part search for convenience. i'll close it.
Session not pickleable when using DigestAuth and Python3.6

A requests session cannot be pickled when using DigestAuth and Python3.6 because of this bug with Python3 - https://bugs.python.org/issue28967 and the referenced issue in that issue - https://bugs.python.org/issue22995 (Tested working with Python3.5.4).

## Expected Result
Pickle call succeeds.

## Actual Result
Exception. 
```
C:\Dev\virtual_envs\play_3\Scripts\python.exe C:/Dev/play/requestspickle.py
Traceback (most recent call last):
  File "C:/Dev/play/requestspickle.py", line 7, in <module>
    session_pickle = pickle.dumps(session)
TypeError: can't pickle _thread._local objects
```

## Reproduction Steps

```python
import pickle
import requests
from requests.auth import HTTPDigestAuth

session = requests.Session()
session.auth = HTTPDigestAuth('user', 'passwd')
pickle.dumps(session)
```

## System Information

    $ python -m requests.help

```
{                                  
  "chardet": {                     
    "version": "3.0.4"             
  },                               
  "cryptography": {                
    "version": ""                  
  },                               
  "idna": {                        
    "version": "2.6"               
  },                               
  "implementation": {              
    "name": "CPython",             
    "version": "3.6.3"             
  },                               
  "platform": {                    
    "release": "7",                
    "system": "Windows"            
  },                               
  "pyOpenSSL": {                   
    "openssl_version": "",         
    "version": null                
  },                               
  "requests": {                    
    "version": "2.18.4"            
  },                               
  "system_ssl": {                  
    "version": "100020bf"          
  },                               
  "urllib3": {                     
    "version": "1.22"              
  },                               
  "using_pyopenssl": false         
}                                  
```

Closed due to inactivity.
Requests session adapter doesn't retry incomplete chunked responses, unlike urllib3

IncompleteRead error from chunked responses are not retried with requests session and HTTPAdapter using Retry. If I use urllib3 directly, it's retried.

## Expected Result
Similar to urllib3, it should be retried. IncompleteRead is a read error and Retry utility specifically states to support retrying of read errors.

## Actual Result
It's not retried, raising ChunkedEncodingError instead

## Reproduction Steps

```python
import pytest
import requests

from requests.adapters import HTTPAdapter
from requests.exceptions import ChunkedEncodingError
from requests.packages.urllib3.util.retry import Retry
from urllib3 import PoolManager
from urllib3.exceptions import MaxRetryError

# This is bad example because it also returns content length header but this is the easiest way I found to reproduce.
URL = "https://httpbin.org/response-headers?Content-Type=text%2Fplain%3B+charset%3DUTF-8&Transfer-Encoding=chunked&Server=httpbin"


@pytest.fixture
def retries():
    return Retry(total=2)


def test_requests_session_retry(retries):
    adapter = HTTPAdapter(max_retries=retries)
    session = requests.Session()
    session.mount('https://', adapter)
    with pytest.raises(ChunkedEncodingError):
        session.get(URL)


def test_urllib3_retry(retries):
    http = PoolManager(retries=retries)
    with pytest.raises(MaxRetryError):
        response = http.request('GET', URL)

```

## System Information

```
$ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.1.4"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.0"
  },
  "platform": {
    "release": "3.13.0-133-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010007f",
    "version": "17.5.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000106f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}

```

I believe your urllib3 example is incomplete. Requests does this:

```py
response = http.request('GET', URL, preload_content=False)
for chunk in response.stream():
    # build up requests.Response.content
```

If I do that, I get the same problem in urllib3. (Although it's raised as a ProtocolError ... which you can see in the Requests traceback chain.)

Does it mean "working as intended" ? Still it sucks that one has to apply additional layer of retry logic on top of existing retry utility..

My comment means: This is not a bug in Requests. It should be discussed in urllib3 but I do not believe that we can handle this there as the Retry logic lives closer to the send functionality, and only works well if we do preload the body.
Requests and urllib3 giving "bad handshake: SysCallError(-1, 'Unexpected EOF')" in a proxied environment  on a non standard port

Summary.

Are urllib3 and/or requests modules facing problems when it comes to accessing HTTP(S) service(s) on non standard ports?

## Expected Result

>python
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>import requests
>>requests.get('https://somehost.com:8443', verify=False)

InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
<Response [200]>

This is what is expected

## Actual Result

What happened instead.
![image](https://user-images.githubusercontent.com/12440040/38110490-b96329ce-3350-11e8-803f-9dc3dd4220f9.png)

I have referenced these blogs:
https://www.bountysource.com/issues/30782175-requests-exceptions-sslerror-eof-occurred-in-violation-of-protocol-_ssl-c-645

https://github.com/requests/requests/issues/4272

>pip freeze
asn1crypto==0.24.0
astroid==1.6.2
attrdict==2.0.0
cachetools==2.0.1
certifi==2017.7.27.1
cffi==1.11.5
chardet==3.0.4
colorama==0.3.9
cryptography==2.1.4
future==0.16.0
idna==2.6
isort==4.3.4
lazy-object-proxy==1.3.1
mccabe==0.6.1
ndg-httpsclient==0.4.4
pefile==2017.11.5
pika==0.10.0
prompt-toolkit==1.0.15
protobuf==3.4.0
pyasn1==0.4.2
pycparser==2.18
Pygments==2.2.0
pylint==1.8.3
pyOpenSSL==17.5.0
python-dateutil==2.6.1
PyYAML==3.12
requests==2.18.4
six==1.11.0
urllib3==1.22
wcwidth==0.1.7
wrapt==1.10.11

>openssl version
OpenSSL 1.0.2k  26 Jan 2017

>python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 1.0.2d 9 Jul 2015


## System Information

    > python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.1.4"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.0"
  },
  "platform": {
    "release": "",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "1010007f",
    "version": "17.5.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000204f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```

Any help would be appreciated. 

@Lukasa i have tried solutions on your other blogs i mentioned above and none of them worked. I just wanted a bit more guidance.

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.

`Unexpected EOF` means your server is closing the connection while we're trying to perform the TLS handshake. That's not a requests bug. For help with that, go to StackOverflow.
Url with vertical bar

I found if we have "|" vertical bar in url will show

Expecting value: line 9 column 1 (char 16)

The following is my code...

req = requests.session()
req.get('http://mis.twse.com.tw/stock/index.jsp',headers={'Accept-Language': 'zh-TW'})   
response = req.get(self.query_url)
print(content)


self.query_url is aurl have "|" 

For example:

http://mis.twse.com.tw/stock/api/getStockInfo.jsp?_=1522229112409&json=1&delay=0&ex_ch=tse_3374.tw|tse_2455.tw|tse_8086.tw|tse_3105.tw|tse_4991.tw|tse_2360.tw|tse_4971.tw|tse_6271.tw|tse_2448.tw|tse_2454.tw|tse_3443.tw|tse_3661.tw|tse_3035.tw|tse_2376.tw|tse_2377.tw


## Expected Result

I hope I can read url with "vertical bar" 

## Actual Result

Expecting value: line 9 column 1 (char 16)

## Reproduction Steps

```python
import requests

req = requests.session()
req.get('http://mis.twse.com.tw/stock/index.jsp',headers={'Accept-Language': 'zh-TW'})   
response = req.get('http://mis.twse.com.tw/stock/api/getStockInfo.jsp?_=1522229112409&json=1&delay=0&ex_ch=tse_3374.tw|tse_2455.tw|tse_8086.tw|tse_3105.tw|tse_4991.tw|tse_2360.tw|tse_4971.tw|tse_6271.tw|tse_2448.tw|tse_2454.tw|tse_3443.tw|tse_3661.tw|tse_3035.tw|tse_2376.tw|tse_2377.tw'
)
content = json.loads(response.text)
print(content)
```

## System Information

version python3.6

I cannot reproduce this locally on Python 3.6 with 

```json
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.3"
  },
  "platform": {
    "release": "17.4.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020ef"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

There isn't enough detail to help and I'm closing this. If you need help with code, please visit [StackOverflow](https://stackoverflow.com) as our issue tracker is only for bugs.

I am sorry I modify the Reproduction Steps...  
Can you reproduce this again, please?

@jerbluba with those refined, this firmly falls into Not a Bug territory. The JSON module (not provided by Requests) cannot decode something that isn't JSON, thus you need to handle that body separately. StackOverflow is the right place for this discussion.

But I observe it by Wireshark，the "vertical bar" become "%7C" ，so I can't get json data from the url.

Please help me.

![vertical_bar](https://user-images.githubusercontent.com/6846724/38101517-150fe228-33b3-11e8-98e0-c6158ccc397e.PNG)
TypeError: request() got an unexpected keyword argument 'file'

In the documentation it is written that so it is possible to make a request, but there is an exception.
I first tested it on version 2.12.4.
And then checked on the latest available (2.18.4).

http://docs.python-requests.org/en/stable/user/quickstart/#post-a-multipart-encoded-file

## Expected Result

Running the query

## Actual Result

TypeError: request() got an unexpected keyword argument 'file'

## Reproduction Steps

```python
import requests

payload = {"param_1": "value_1", "param_2": "value_2"}
files = {
                'json': (None, json.dumps(payload), 'application/json'),
                'file': ('log', "11" )
}
post = requests.post(API_HOST+API_URL, file=files)
print(post.content)
```

## System Information

    $ python -m requests.help

```
root@5cf05c9a3e78:/app# python3 -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.3"
  },
  "platform": {
    "release": "4.9.0-6-amd64",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1010006f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

excuse me. I was inattentive


I ran into the same issue — could you tell, how you worked it out?

Argh, got it: the keyword is 'files', not 'file'.
respect reply-afer in automatic redirects

small patch that respects replay-after only in automatic redirects .. similar to chrome, firefox and others.

 reply-after is not handled for other status codes such as 503, and 429 as the handling may application specific.  

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After

There's already logic for respecting the `Retry-After` header within urllib3, one of Requests core modules. You may need to write your own Adapter in order for this logic to be used.

We did not see it being respected.

we have seen web-sites  returning 30X with retry-after headers and we hit
max-redirects < 1 seconds while the site has exponential backoff.
These redirects are handled by major browsers correctly waiting the
assigned period.

II have scanned the urllib3 docs but did not come across any mention of the
header handling.. can you point me to it or some way to enable it ?

Thanks,



On Tue, Mar 27, 2018 at 2:59 PM, Seth M. Larson <notifications@github.com>
wrote:

> There's already logic for respecting the Retry-After header within
> urllib3, one of Requests core modules. Is that not already being leveraged?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/requests/requests/pull/4562#issuecomment-376689647>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABtToApXulkzVvFYUzJVWHZ4YyAK22hBks5tirYwgaJpZM4S9rkS>
> .
>



-- 
Kristian G. Kvilekval (kkvilekval@gmail.com) 805-636-1599


See the parameter: `respect_retry_after_header` in the [documentation](https://urllib3.readthedocs.io/en/latest/reference/urllib3.util.html#urllib3.util.retry.Retry) and on [GitHub](https://github.com/shazow/urllib3/blob/master/urllib3/util/retry.py#L138).

Hi @kgk, @SethMichaelLarson is right that urllib3 provides this functionality and it would be better to try and leverage that. The issue with redirects is that we don’t use urllib3 for those and instead create a new request ourselves. I know there are historical reasons for this but I can’t find an issue for reference immediately. I’ll try to take a look into what would be needed to support this tonight.

A quick look at adapters.py makes me think it would be hard to put at
urllib3 level since redirects are specifically disabled.  Solutions such as
covered here
https://www.peterbe.com/plog/best-practice-with-retries-with-requests make
sense for the 503 and 429 status codes.   But requests is handling 30X
internally (when allow_redirects is enabled) so it may need to also handle
the requested delays.



You can leverage urllib3 retries directly as described [here](http://www.coglib.com/~icordasc/blog/2014/12/retries-in-requests.html)

As mentioned by @nateprewitt  redirect are disabled in urllib3 by requests.  Retries (on failed connects, reads etc) can be implemented as described by @sigmavirus24 , but since redirects are not handled there it cannot be used.   For the record, I have confirmed that urllib3 does support the retry-after header while requests does not.
Incompatibility with CX-Freeze and PyInstaller

As reported on [StackOverflow](https://stackoverflow.com/a/41718977/2073217), the latest Requests version dies on initialization in an app frozen app by CX-Freeze / PyInstaller.  But Requests version 2.11.1 works OK. 

## Expected Result

The current versions of Requests run without exception,  like version 2.11.1 does.

## Actual Result

This exception occurred:

Traceback (most recent call last):
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\cx_Freeze\initscripts\__startup__.py", line 14, in run
    module.run()
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\cx_Freeze\initscripts\Console.py", line 26, in run
    exec(code, m.__dict__)
  File "PythonSocketIoClient.py", line 5, in <module>
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\socketIO_client\__init__.py", line 14, in <module>
    from .transports import (
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\socketIO_client\transports.py", line 1, in <module>
    import requests
  **File "C:\PythonEnvs\CL\Client32\lib\site-packages\requests\__init__.py", line 98, in <module>**
    from . import packages
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\requests\packages.py", line 7, in <module>
    locals()[package] = __import__(package)
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\idna\__init__.py", line 2, in <module>
    from .core import *
  File "C:\PythonEnvs\CL\Client32\lib\site-packages\idna\core.py", line 1, in <module>
    from . import idnadata
**ImportError: cannot import name 'idnadata'**


## Reproduction Steps

Run CX-Freeze (or PyInstaller) with the appropriate Requests version installed, to compare the results.


## System Information

{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.4"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

Hi @dcsoft4, this is either an issue with your local installation or PyInstaller. It can’t find resources for idna which are a requirement for modern versions of Requests. Ensure you have idna installed properly and see if that fixes the issue.

In the future, please route questions for assistance to [StackOverflow](https://stackoverflow.com) with the python-requests tag. We’re happy to follow up over there. We try to keep the issue tracker solely for defects in Requests which this doesn’t appear to be. Thanks!

There are also numerous examples of other issues which are already closed and solved to research. Please always search closed issues before opening new ones.
Session timeout / Added the ability to set a default session timeout

This is a very minimal PR that aims to allow developers to assign a default timeout to requests made using `Requests`, while not breaking any existing usage of the library. I open it following bumping into the problem of a request hanging indefinitely several times and reading through the open issues - specifically @kennethreitz 's comment here regarding assigning a default timeout to the lib: https://github.com/requests/requests/issues/3070#issuecomment-318926146

In essence, it allows a user to set a default timeout for a `Session` object so that any request made using that session will default to the session timeout unless specifically assigned a timeout of its own. I attempted to circumvent the entire issue of breaking existing code or deciding on the right default timeout for the library itself, instead just giving the user a tool to set it per session where necessary, instead of once per request.

The only open issue I am aware of is that if a request is specifically assigned to never timeout (`timeout=None`) and the session it is sent from has a default timeout set, then the session timeout will take. However, I believe that in such a case it makes sense to send the request from a new session.

Happy to receive any feedback. Thanks in advance!

Thanks for putting this together. I don’t think it will be accepted. In the past this library supported session-level timeouts but this proved to be unintuitive to most users as they expected various different things. We intentionally removed the feature, with prejudice. Adding it back at this time is unlikely.

@sigmavirus24 Thanks for addressing my PR so promptly. I find it hard to advocate adding this when I don't have any knowledge of past issues with such a mechanism. I failed to find resources for this when looking through the issues - are there any specific issue threads you can point me to? Is proper implementation of this feature in a non-confusing way something that you're even willing to discuss?
requests.exceptions.ConnectionError

How can I deal with this error?
requests.exceptions.ConnectionError: HTTPConnectionPool(host='cloud.ocrsdk.com', port=80): Max retries exceeded with url getTaskStatus?taskId=5d9d39a9-4cd2-4528-aeeb-a1d84cc342c7 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdc0f230320>: Failed to establish a new connection: [Errno 110] Connection timed out',))


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.

@Everfighting  I encountered the same problem, how did you solve it ？
wrong condition returning true only if there's the same domain repeated

https://github.com/requests/requests/blob/b66908e7b647689793e299edc111bf9910e93ad3/requests/cookies.py#L295

Hi @kamiswim, you’re right that this doesn’t look correct. The behavior doesn’t match the doctstring and doesn’t make much sense.

We don’t utilize domains in our cookie implementation but it’s been a goal for a while. It’s likely this method has seen little usage which is why it’s escaped notice this long. I think we should definitely fix this in 3.0 but I’m not sure if we have users that are depending on this current behavior now.

If you would like to open a PR fixing this to the proposed/3.0.0 branch, we’re happy to review that. That is unless @sigmavirus24 thinks we should fix it on master.

closing due to inactivity
Line break in cookies breaks headers

I am posting data to an API. I came across a weird issue where the site returned a cookie with a 'line break' in it. Now the site wasn't purposefully trying to give cookies with line breaks, it just happened by chance. This is a authentication cookie and therefore stripping out the newline doesn't work.

## Expected Result

The post to work as expected.

## Actual Result

ValueError: Invalid header value '__urqm=37855709~a7638d6cc5309346d88260d67bc5aacd~BfI-nlTM1zqM; __urqc=3d2ff94a-7737-439e-ab33-5098cb7f1b6d; __urqi=b488782e25c7908\nd88648ac0bdb39b0138c8b6f851b65bba410f9e836b9e9b2de449b73dac3c091fc06a070e52ec282b71017c06a2164dd0ab4208294e2b18b9'

I eventually debugged the '\n' inside of the _urqi cookie. 

## Reproduction Steps

```python
import requests

cookies = {
    '__urqc': '3d2ff94a-7737-439e-ab33-5098cb7f1b6d',
    '__urqm': '37855709~a7638d6cc5309346d88260d67bc5aacd~BfI-nlTM1zqM',
    '__urqi': 'b488782e25c7908\nd88648ac0bdb39b0138c8b6f851b65bba410f9e836b9e9b2de449b73dac3c091fc06a070e52ec282b71017c06a2164dd0ab4208294e2b18b9'
}

headers = {
    'Origin': 'https://www.mypoints.com',
    'Accept-Encoding': 'gzip, deflate, br',
    'Accept-Language': 'en-AU,en;q=0.9,fr;q=0.8,en-US;q=0.7',
    'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36',
    'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
    'Accept': '*/*',
    'Referer': 'https://www.mypoints.com/videos',
    'Connection': 'keep-alive',
    'DNT': '1',
}

params = (
    ('cmd', 'mp-wa-playlist'),
)

data = [
  ('playlistid', '9226'),
  ('__mBfuPAgT', '2b674ad0ee62707f2236e12c2cadb44d62f6a9019d50437bb5c9c8b0096e4491'),
]

response = requests.post('https://api.mypoints.com/', headers=headers, params=params, cookies=cookies, data=data)
```

## Workaround

Simply changing the '\n' inside the cookie to '\\n' the request works.
cannot import name "async" Python 3.6 with gevent

the line: `from requests import async`
fails with the following message: `ImportError: cannot import name 'async`
on my linux install with Python 3.6.3, gevent 1.2.2. and requests 12.18.4

## Expected Result

Expected the module to successfully load

## Actual Result

Error message thrown

## Reproduction Steps

from the command line:
`pip install gevent requests`
then from the interpreter
```python
from requests import async
```

## System Information

    $ python -m requests.help

```
(venv) akcom@ubuntu:~/Projects$ python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.3"
  },
  "platform": {
    "release": "4.13.0-37-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

Likewise
```
pip freeze | egrep -i '(gevent|request)'
```

returns

```
gevent==1.2.2
requests==2.18.4
```

Edit: somehow google took me to the v0.10.6 documentation (http://docs.python-requests.org/en/v0.10.6/user/advanced/) which is out of date.  For anyone else who sees this, please use [this](https://github.com/kennethreitz/grequests) or [this](https://github.com/requests/requests-threads) instead.
Updated types in __init__.py according to types.py


# [Codecov](https://codecov.io/gh/requests/requests/pull/4551?src=pr&el=h1) Report
> Merging [#4551](https://codecov.io/gh/requests/requests/pull/4551?src=pr&el=desc) into [3.0](https://codecov.io/gh/requests/requests/commit/8f3f022c54db7c8348c84c079dfe7f7c354f1062?src=pr&el=desc) will **increase** coverage by `0.01%`.
> The diff coverage is `100%`.

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

```diff
@@            Coverage Diff             @@
##              3.0    #4551      +/-   ##
==========================================
+ Coverage   90.03%   90.04%   +0.01%     
==========================================
  Files          16       16              
  Lines        1645     1647       +2     
==========================================
+ Hits         1481     1483       +2     
  Misses        164      164
```


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

------

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


Hi @RatanShreshtha, thanks for putting this together. I'd like @kennethreitz to give this a glance over and determine if we need it in 3.0.

Thanks for contributing to Requests, @RatanShreshtha! We'll go ahead and merge this now.
wget --no-check-certificate http://cdn.grupomabis.inet/cfssl/ca.pem -O /usr/local/etc/openssl/certs/cfssl-ca.pem wget --no-check-certificate http://cdn.grupomabis.inet/certs/web.pem -O /usr/local/etc/openssl/certs/cfssl-web.pem /usr/local/opt/openssl/bin/c_rehash

Summary.

## Expected Result

What you expected.

## Actual Result

What happened instead.

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
<paste here>
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).
[RFC for 3.0] Make `verify=False` less desireable for users

Maybe we could use the opportunity of breaking with things in 3.0 to nag users about reverting many users behaviour of specifying `verify=False` and squelching the resulting warnings by default.

One way would be to introduce a new warning or putting `verify=False` into eternal deprecation mode.

Pros:

* May lead users to adapt their code to be more secure

Cons:

* Will probably lead to more tickets here and questions on SO
* Could be interpreted as a intentional breaking existing stuff, ill meaning
* Could lead users to inhibit all `DeprecationWarning`s by default

I am actually not completely convinced this is worth the hassle to be honest, but think it is worthy of a discussion.
(Counting a short "The heck?! no way!" as a discussion here)

Cc @sigmavirus24 @Lukasa @kennethreitz 

I intend to have no change here, personally.

I think there are legitimate reasons to verify=False (sometimes you just legitimately don't care), and we shouldn't disempower those use cases.
socks5 not work for session proxies property

this is not work,
```python
import requests

sess = requests.session()
proxy = 'socks5://1.1.1.1:9994'
sess.proxies = {'http': proxy, 'https': proxy}

res = sess.get('https://httpbin.org/ip', verify=False)
print(res.text)
```

but this is ok
```python
import requests

sess = requests.session()
proxy = 'socks5://1.1.1.1:9994'
proxies = {'http': proxy, 'https': proxy}

res = sess.get('https://httpbin.org/ip', verify=False,proxies=proxies)
print(res.text)
```
if requests that use socks5 too many，many port in  TIME_WAIT,how to fix it?

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

I'll be logging what I'm working on in this pull request. 

So far: 

- Removed all Python 2-specific code.
- Ran codebase through Black (White, actually) (new `setup.py format` command).
- Converted many `str.format`s to f-strings.
- Removed many "if bytes" code paths.
- Integrated rfc3986 for URL Parsing (needs to be done in `utils.py` still.
- Integrated new `HTTPHeaderDict`. 
- Typed out `api.py` and `utils.py` (I think, correctly), added a new types module, `types.py`. 
- Updated test suite to use a session fixture. 
- Added `__slots__` to most heavily-used classes.

**This pull request is not a request for feedback.**

All tests passing.

Think that's everything. Will add comments as I go.

Need to clean up AppVeyor, apparently.

AppVeyor's working! ✨🍰✨

Name–squatted "requests3" on PyPI. I'm liking that idea more and more for v3.

Are the imports and checks of chardet, pyopenssl & cryptography still needed once Python 2 is dropped?

I ask, as my CLI applications are really sensitive to import time / human perception of how fast the command is, and these modules add a fair amount of import overhead, as found via "python3.7 -Ximporttime"

Thanks

> Are the imports and checks of chardet, pyopenssl & cryptography still needed once Python 2 is dropped?

- chardet is required across Py2 and 3.
- `pyopenssl`/`cryptography` will likely be needed as we continue to support older Python 3 versions that aren't as secure as the latest.

As for the `checks`, I'm guessing you mean version checks. In which case, we will not drop those because it's our only mechanism for telling users they're using unsupported software configurations that mean we will not help them with bugs.

> I ask, as my CLI applications are really sensitive to import time / human perception of how fast the command is, and these modules add a fair amount of import overhead, as found via "python3.7 -Ximporttime"

Yes, cryptography adds import time and so does chardet. I'm surprised you haven't complained about idna as well since that also adds a lot of overhead just by importing it. There's little we can do to reduce that without outright removing features (automatic character encoding detection (chardet), security (pyopenssl/cryptography), internationalized domain name handling (idna)) that are standard for HTTP clients in any language.

@sigmavirus24 I agree overall (and I'm not sure why idna didn't show up in my imports), however - for environments where none of that functionality is needed, it would be nice to have a way to disable those imports.

I'm happy to block them via a sys.modules hack, but the version checking & other usage code (such as "def apparent_encoding" assume these modules are there. If you would be open to selective loading or deferred loading, I can create a PR.

Closing this as it hasn’t been actioned on in a few years.
AttributeError: 'NoneType' object has no attribute 'read' (client.py:612)

## Expected Result
Sending a request with request.get(url, data=data) should return a normal web response.

## Actual Result
```
  File "d:\VSWorkspace\MyWebClient.py", line 64, in query_api
    response = requests.get(url, data=query)
  File "C:\Program Files\Python36\lib\site-packages\requests\api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "C:\Program Files\Python36\lib\site-packages\requests\api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Program Files\Python36\lib\site-packages\requests\sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Program Files\Python36\lib\site-packages\requests\sessions.py", line 658, in send
    r.content
  File "C:\Program Files\Python36\lib\site-packages\requests\models.py", line 823, in content
    self._content = bytes().join(self.iter_content(CONTENT_CHUNK_SIZE)) or bytes()
  File "C:\Program Files\Python36\lib\site-packages\requests\models.py", line 745, in generate
    for chunk in self.raw.stream(chunk_size, decode_content=True):
  File "C:\Program Files\Python36\lib\site-packages\urllib3\response.py", line 432, in stream
    for line in self.read_chunked(amt, decode_content=decode_content):
  File "C:\Program Files\Python36\lib\site-packages\urllib3\response.py", line 601, in read_chunked
    chunk = self._handle_chunk(amt)
  File "C:\Program Files\Python36\lib\site-packages\urllib3\response.py", line 566, in _handle_chunk
    returned_chunk = self._fp._safe_read(self.chunk_left)
  File "C:\Program Files\Python36\lib\http\client.py", line 612, in _safe_read
    chunk = self.fp.read(min(amt, MAXAMOUNT))
AttributeError: 'NoneType' object has no attribute 'read'
```

## System Information
```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.4"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

side note: my pylint in Visual Studio Code shows 8 errors in client.py: 6 constants that are undeclared, one global variable that's undeclared, and one index error that looks to be related to not declaring the variable type in the method definition. But I'm using python 3.6.4, so it could just be a compatibility issue in my pylint version.

Duplicate of #3698

So, if I'm understanding this correctly...

requests isn't handling `ERR_EMPTY_RESPONSE` (that you'd see in a browser) properly?
Added type hints for help.py.

This my first PR to this project please review and give feedback to me how can I improve.

Is Dict proper here, or MutableMapping? Learning myself :)

Actually, let's have this import from `requests.types`

@RatanShreshtha made some changes, please review for future PRs :)

thanks, @kennethreitz  so for future I should use the types .py?

@RatanShreshtha correct!
http redirect to non http causes exception

Summary.
If a http page redirects via 301 to a non-http location, eg a magnet link, requests raises exception and the redirect link is not available except in the error text
## Expected Result
Would be better if it returned status_code=301 and content=redirect link
## Actual Result
exception No connection adapters were found for 'magnet:?xt=urn:btih...

Hi @philborman, thanks for reporting this. This is actually a duplicate of #4362, which I think @kennethreitz's needs to take a look at. The `request.next` feature broke handling custom schemes, so until that's resolved, Requests 2.16+ isn't able to handle non-http style URI redirects.

Not quite, I haven't disabled redirects like #4362   I want the redirect to be followed providing its the same type (http redirects to http)  but if it's a different schema or an invalid schema return the status code and content so it can be handled by the calling app.

My use case:
Downloading a torrent or magnet
If the torrent (http) is moved to a new location (http), requests redirect will handle it
If the torrent redirects to a magnet link, don't throw an exception, return the 301 status and provide the new location in the response content so my app can decide what to do.

@philborman that's something that is easily implemented with a small redirect function when our default behaviour is disabled. That's the reason we added the `allow_redirects` functionality initially. Until that's fixed, I don't know if we can do a lot here. 

Maybe I am getting it wrong then. I tried with allow_redirects set to False and got a 301 status_code but the contents was empty so no way of knowing where the redirect pointed to. I could only get that by allowing redirects to cause the exception  and then scanning the error text for the new location. Messy, but it works.  Thanls for your quick response. 

@philborman you get the location of the redirect from the 'Location' header, not the body
Please update docs to reflect that using the json kwarg in requests results in Content-Type being set to application/json

Wanted to make sure that the Content-Type was set to application/json when the json kwarg is used `requests.post(..., json=some_data)`, but could not find this anywhere in the documentation.

## Expected Result
Expected to find at least a short one sentence blurb about this in the documentation

Pull requests accepted :)

I'll update this!
POST request with 400 response throws ConnectionError

I make a POST request to an internal API. When some preconditions are not met the API responds with 400.

## Expected Result

Getting a response object with status_code == 400

## Actual Result

requests throws excpetion with ConnectionError

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.4"
  },
  "platform": {
    "release": "4.4.0-81-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "20000000"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

Additional information: This happens when the payload of the request was not received, yet. So it seems, requests can't handle this interruption.

Even more information: Only happens when data parameter is a file object created with open.

@sebastianbauer there isn't enough information here to properly debug this. At a minimum we'll need the stacktrace so we can identify what kind of `ConnectionError` you're seeing, and preferably you'd also include a snippet of code to reproduce the issue.

Is this reproducible on more servers than your own? If not, this is likely a behavior in the interaction of your two code bases which is causing an issue. In that case, we'd prefer this was followed up on [StackOverflow](https://stackoverflow.com) which we have designated as a place for Requests questions/assistance inquiries. This issue tracker is specifically for reproducible defects in Requests. Thanks!

@nateprewitt Thanks for your comment. I investigated further and it actually is not an issue with requests itself, but some underlying libs. It belongs to this one: https://bugs.python.org/issue25919

Sorry for the trouble.

No problem, thanks for checking back in! Closing since there's nothing left to address here.
Issue #4518 - Update MANIFEST.in

Update MANIFEST.in (Issue #4518)

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

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



------

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