Raibek/requests-github-issues huggingface dataset:
Add an enhancement for transforamtion between dict and cookiejar.

When using dict_from_cookiejar, I can only get name and value from cookie object, otherwise other cookie attributes are lost. So I want to make an enhancement about two methods dict_from_cookiejar and cookiejar_from_dict, which can be more flexible and safe to do cookie transformation and persistence like the following code.

```
import requests
from requests.utils import dict_from_cookiejar

res = requests.get('https://github.com/justdoit0823/notes')

dict_from_cookiejar(res.cookies)

dict_from_cookiejar(res.cookies, with_cookie_attr=True)
```

And the output:

```
#  with_cookie_attr is False
{'_gh_sess': 'somevalue', 'logged_in': 'no'}

#  with_cookie_attr is True
{'_gh_sess': {'discard': True,
  'domain': 'github.com',
  'name': '_gh_sess',
  'path': '/',
  'rest': {'HttpOnly': None},
  'rfc2109': False,
  'secure': True,
  'value': 'somevalue',
  'version': 0},
 'logged_in': {'discard': False,
  'domain': '.github.com',
  'expires': 2126671044,
  'name': 'logged_in',
  'path': '/',
  'rest': {'HttpOnly': None},
  'rfc2109': False,
  'secure': True,
  'value': 'no',
  'version': 0}}
```

Thanks for this patch! I'm afraid I don't think it's necessary: these are primarily intended as internal utilities and so we're very disinclined to add features to them. Sorry about that! :sparkles:
More Verbose Execption Handling

So I tried to add more verbose exception handling without breaking current functionality (this feels really hacky).  It seems to me that it may be pertinent to break these out and not raise a connection error for each request (as denoted in : https://github.com/kennethreitz/requests/issues/2876)

In the current implementation, a ConnectionError is raised for each call, as well as a max retries message.  It seems like the max retries message error should either be removed or made as more of a general string response statement.  This general string response is here:
https://github.com/kennethreitz/requests/blob/master/requests/adapters.py#L503

Doing so would require removing that line and adding explicit responses within that max retry block, but this might break current functionality if people are depending on the response from requests to make other decisions.

Looking forward to a discussion on this topic.


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

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

```diff
@@            Coverage Diff            @@
##           master   #4047      +/-   ##
=========================================
- Coverage   89.74%   89.7%   -0.05%     
=========================================
  Files          15      15              
  Lines        1941    1943       +2     
=========================================
+ Hits         1742    1743       +1     
- Misses        199     200       +1
```


| [Impacted Files](https://codecov.io/gh/kennethreitz/requests/pull/4047?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/adapters.py](https://codecov.io/gh/kennethreitz/requests/pull/4047?src=pr&el=tree#diff-cmVxdWVzdHMvYWRhcHRlcnMucHk=) | `92.05% <50%> (-0.87%)` | :arrow_down: |
| [...es/urllib3/packages/ssl\_match\_hostname/\_\_init\_\_.py](https://codecov.io/gh/kennethreitz/requests/pull/4047?src=pr&el=tree#diff-cmVxdWVzdHMvcGFja2FnZXMvdXJsbGliMy9wYWNrYWdlcy9zc2xfbWF0Y2hfaG9zdG5hbWUvX19pbml0X18ucHk=) | `96.66% <0%> (+3.33%)` | :arrow_up: |

------

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


Closing this in favor of parsing the execution in the client code.
Add setup.cfg to declare wheel as universal

As the project is pure Python, a built wheel should always be universal,
so define in the project globally. Can remove --universal command from
Makefile.

See:

http://pythonwheels.com/

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

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

```diff
@@           Coverage Diff           @@
##           master    #4041   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1941     1941           
=======================================
  Hits         1742     1742           
  Misses        199      199
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4041?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/kennethreitz/requests/pull/4041?src=pr&el=footer). Last update [fb3f2a0...2c71f2d](https://codecov.io/gh/kennethreitz/requests/pull/4041?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Two transport 'location' headers cause an incorrect url

I noticed a bug while trying to simulate a login process for a service. At some point I receive a 302 response where there are two Location headers.

```
HTTP/1.1 302 Found
Location: https://some_url.com/
Accept-Ranges: bytes
Location: https://some_url.com/
```

While using the ```Session``` object, I noticed that both Location values are merged into one value like this:
```python
{'Location':'https://some_url.com/, https://some_url.com/'}
```

I added a temp split solution into ```SessionRedirectMixin.get_redirect_target()```, but I was wondering if you could come up with a permanent fix for this please?

```python
if resp.is_redirect:
            location = resp.headers['location']
            location = location.split(', ')[0]
```

Thanks in advance.


So I'm rather certain this is an issue with urllib3's Header handler. It needs a whitelist of which headers are allowed to be repeated and which can be joined with a `,` like you found here.

Hey @evgenykovalyov, thanks for taking the time to open this issue. This is actually a dupe of #2939 and should be solved in Requests 3.0.0 with #3417. You'll likely have to wait until that's released for a more permanent solution. That is unless @sigmavirus24 has something else in mind.

I'm going to close this as resolved for now. Thanks again!
Pin sphinx

This will fix the build issues in Python 2.6 due to Sphinx's new requirement of `typing` in versions 1.6+. This pinning (capping) should only be in place until a solution for representing markers is introduced in Pipfile.

While we're here doing cleanup, I've also removed the no longer needed `pipenv lock` before each build. Some preliminary tests show it saving 15-20% on the total build time for CI. We can scrap that though if it's not inline with the goal of the PR, getting the build working.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4036   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1940     1940           
=======================================
  Hits         1741     1741           
  Misses        199      199
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4036?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/kennethreitz/requests/pull/4036?src=pr&el=footer). Last update [0280a18...dbdbffd](https://codecov.io/gh/kennethreitz/requests/pull/4036?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
The case of the haunted stream request

Hi,

I'm not sure if this is a bug in `requests` or a misconfiguration in the server I'm interacting with, but I have the following very puzzling result:
```python
>>> from requests import get
>>> response = get('http://edok01.tib.uni-hannover.de/edoks/e01dh15/815761511.pdf', stream=True)
>>> next(response.iter_content(4))
'%PD'
```
which returns 3 characters instead of the 4 that I requested, but also:
```python
>>> from requests import get
>>> response = get('http://edok01.tib.uni-hannover.de/edoks/e01dh15/815761511.pdf', stream=True)
>>> iter = response.iter_content(1)
>>> next(iter)
'%'
>>> next(iter)
'P'
>>> next(iter)
'D'
>>> next(iter)
'F'
```
which instead returns all the 4 characters. Note also that this happens with both `unicode_decode=True` or `unicode_decode=False`.

How is this possible? This is happening with `requests==2.14.2`. The description of the problem in https://github.com/kennethreitz/requests/issues/3980#issue-223287665 looks relevant, but its fix in #3984 looks less relevant. In fact, I still see the problem on a local checkout of `master`.

`iter_content` transparently decompresses gzipped data received from the server. This means that when we receive bytes from the network we don't know how many bytes that will actually resolve into. For that reason, we don't guarantee that you'll get literally that number of bytes: we just promise that you won't get the empty string. That's why `iter_content(1)` appears to "work".

This is the expected behaviour, I'm afraid.

Ah, thanks a lot. At one point I had the feeling it had something to do with compression, but I didn't investigate in that direction.
POST header Content-Length with negative value

Im new to requests and to http methods.
Im trying to test an server accepting http calls. As part of validation, Im trying to set negative value to 'Content-Length' header and expect 400 'Bad request' but requests.post() returns 200.
I also observed that in POST request headers, content-length is modified to actual value as per the file data being uploaded.

```python
In [75]: headers={'Date': 'Wed, 17 May 2017 08:45:39 GMT', 'Content-Length': '-50'}

In [76]: data = open('/tmp/50').read()

In [77]: out = requests.post(url=url, headers=headers, data=data)

In [78]: out.request.headers
Out[78]: {'Content-Length': '50', 'Accept-Encoding': 'gzip, deflate', 'Accept': '*/*', 'User-Agent': 'python-requests/2.14.2', 'Connection': 'keep-alive', 'Date': 'Wed, 17 May 2017 08:45:39 GMT'}

In [79]: out.headers
Out[79]: { 'Content-Length': '37', 'Server': '1/1.0/', 'Connection': 'keep-alive',  'Date': 'Wed, 17 May 2017 18:01:08 GMT'}

In [80]: out.status_code
Out[80]: 201
```
Am i missing something here?
I have tested the same with curl, which responds back with 400 response code.

Requests is not intended as a HTTP testing tool: in particular, it is not intended to allow you to craft malformed HTTP requests. If that's what you're looking for you'll need to find a different tool for that.
Test that the readme renders in CI.

Resolves #4030.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4033   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1940     1940           
=======================================
  Hits         1741     1741           
  Misses        199      199
```



------

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


Merge this when everything else is ✔️
Fix #4025

Fixes #4025 by basically not doing anything when HTTP is used

# [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4029?src=pr&el=h1) Report
> Merging [#4029](https://codecov.io/gh/kennethreitz/requests/pull/4029?src=pr&el=desc) into [master](https://codecov.io/gh/kennethreitz/requests/commit/0280a18b53aef5e09fa0a2886077b0ede5e89e79?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `100%`.

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

```diff
@@            Coverage Diff             @@
##           master    #4029      +/-   ##
==========================================
+ Coverage   89.74%   89.74%   +<.01%     
==========================================
  Files          15       15              
  Lines        1940     1941       +1     
==========================================
+ Hits         1741     1742       +1     
  Misses        199      199
```


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

------

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


I've updated the request with your suggestion. Initially I was thinking about doing this, however it seemed like a bad practice to add random attribute to objects (at least to me). I do agree that it is a simpler fix though.

> Initially I was thinking about doing this, however it seemed like a bad practice to add random attribute to objects (at least to me). 

I get that, but we were already doing it in the line above: this time around we're just being consistent. :wink:

Ah, yes, I forgot the Travis builds are busted. We'll need to hold off until they get fixed.

Ok cool, mind rebasing on the new master?

This looks like you rebased *and* merged in master, so you have duplicate commits. Do you mind fixing that up for me?

Sorry I guess I do not know what I'm doing (have not used rebase before). What would I need to do to fix it?

The other option is I can just handle the merge manually, I suppose. =) Might be the simpler thing to do. Is that suitable to you?

That's fine with me

Ok, I merged manually in fb3f2a030f82475145369b01adbee68d17bd4f43. Thanks for the work!
Session send auth only with one request

Using session object like this:
```
import requests
session = requests.Session()
session.auth = (u'user', 'test')
session.verify = False
response = session.get(url='https://my_url/rest/api/1.0/users')
```
if i looking for this response request headers i see:
`{'Authorization': 'Basic auth_data', 'Connection': 'keep-alive', 'Accept-Encoding': 'gzip, deflate', 'Accept': '*/*', 'User-Agent': 'python-requests/2.12.3'}`
but if i send next request using the same url:
`response = session.get(url='https://my_url/rest/api/1.0/users')`
I can see that where is not auth header in request:
```
print response.request.headers
{'Connection': 'keep-alive', 'Accept-Encoding': 'gzip, deflate', 'Accept': '*/*', 'User-Agent': 'python-requests/2.12.3'}
```

And i getting 401 response because of it.

Why is it so? Shouldnt session send auth with every request made using it? How can i send auth data with every request using session?



Solve problem - it was because of redirect
Include tests in sdist tarball

Fixes: https://github.com/kennethreitz/requests/issues/4024

# [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4027?src=pr&el=h1) Report
> Merging [#4027](https://codecov.io/gh/kennethreitz/requests/pull/4027?src=pr&el=desc) into [master](https://codecov.io/gh/kennethreitz/requests/commit/0280a18b53aef5e09fa0a2886077b0ede5e89e79?src=pr&el=desc) will **decrease** coverage by `0.15%`.
> The diff coverage is `n/a`.

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

```diff
@@            Coverage Diff             @@
##           master    #4027      +/-   ##
==========================================
- Coverage   89.74%   89.58%   -0.16%     
==========================================
  Files          15       15              
  Lines        1940     1940              
==========================================
- Hits         1741     1738       -3     
- Misses        199      202       +3
```


| [Impacted Files](https://codecov.io/gh/kennethreitz/requests/pull/4027?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [...es/urllib3/packages/ssl\_match\_hostname/\_\_init\_\_.py](https://codecov.io/gh/kennethreitz/requests/pull/4027?src=pr&el=tree#diff-cmVxdWVzdHMvcGFja2FnZXMvdXJsbGliMy9wYWNrYWdlcy9zc2xfbWF0Y2hfaG9zdG5hbWUvX19pbml0X18ucHk=) | `83.33% <0%> (-10%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4027?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/kennethreitz/requests/pull/4027?src=pr&el=footer). Last update [0280a18...f823125](https://codecov.io/gh/kennethreitz/requests/pull/4027?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Session with cert set can't do HTTP connections

It is not clear from the documentation if this is supposed to work, but it did work previously.

If you set the cert attribute on a Session and then make an HTTP request, an AttributeError exception is thrown since `key_file` does not exist on an HTTPConnectionPool object. This behavior was introduced in [this commit](https://github.com/kennethreitz/requests/commit/7d8b87c37f3a5fb993fd83eda6888ac217cd108e#diff-31f6e77c031977d33226530924b4337aR243)

From what I can tell it would continue to work if the certificate was set as a tuple instead, since that would then add the key_file attribute to the HTTPConnectionPool a few lines above.

    >>> import requests
    >>> s = requests.Session()
    >>> s.cert='/path/to/file.pem'
    >>> s.get('http://example.com')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 531, in get
        return self.request('GET', url, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 518, in request
        resp = self.send(prep, **send_kwargs)
      File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 639, in send
        r = adapter.send(request, **kwargs)
      File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 407, in send
        self.cert_verify(conn, request.url, verify, cert)
      File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 247, in cert_verify
        if conn.key_file and not os.path.exists(conn.key_file):
    AttributeError: 'HTTPConnectionPool' object has no attribute 'key_file'

Yup, this is definitely a bug. Feel free to take a swing at this if you're interested, otherwise I'll try to fix it tomorrow. 

I've added a pull request. I'm not familiar with the requests code but I think my simple fix of just not doing anything unless HTTPS is used should work (the tests pass at least).
pypi tarballs are missing tests directory

The tests are missing from the pypi tarballs for at least a few releases.

Oddly, when I run `python setup.py sdist` from a git checkout, the resulting tarball does have the tests; I'm not sure how that is working.

Which releases are affected?

@Lukasa, I believe this is related to moving the tests into their own directory starting in 2.10.

#4015 probably should have been to change test_requests.py to 'tests' in MANIFEST.in rather than removing the bad filename.

I checked the tarballs for the following releases, they are all missing the tests directory.

2.11.1
2.12.3
2.13.0
2.14.2

That sounds right @nateprewitt. Want to fix that up with a PR?

Yep, I'll throw the PR up when I get back to a computer, unless you have any interest @floppym.

> Oddly, when I run python setup.py sdist from a git checkout, the resulting tarball does have the tests; I'm not sure how that is working.

This was working for me because I had the `hgdistver` python package installed. This installs a setuptools plugin that auto-detects any files under version control.
Requests issue with PyInstaller: Import error: No module named ordered_dict

I'm trying to create executable for my script, which uses `requests `module.
When running I get error:

>  Import error: No module named ordered_dict

After further inspection the problem occurs in requests/compat.py file, on:
`from .packages.urllib3.packages.ordered_dict import OrderedDict`
I think the the problem is fact, that module is imported from subdirectory, but in my environment requests/packages does not contain other modules, as they are imported externally.
requests/packages/__init__.py contains some workaround that allows to correcly import required libraries:

> '''
Debian and other distributions "unbundle" requests' vendored dependencies, and
rewrite all imports to use the global versions of ``urllib3`` and ``chardet``.
The problem with this is that not only requests itself imports those
dependencies, but third-party code outside of the distros' control too.
In reaction to these problems, the distro maintainers replaced
``requests.packages`` with a magical "stub module" that imports the correct
modules. The implementations were varying in quality and all had severe
problems. For example, a symlink (or hardlink) that links the correct modules
into place introduces problems regarding object identity, since you now have
two modules in `sys.modules` with the same API, but different identities::
    `requests.packages.urllib3 is not urllib3`
With version ``2.5.2``, requests started to maintain its own stub, so that
distro-specific breakage would be reduced to a minimum, even though the whole
issue is not requests' fault in the first place. See
https://github.com/kennethreitz/requests/pull/2375 for the corresponding pull
request.'''
```
from __future__ import absolute_import
import sys

try:
    from . import urllib3
except ImportError:
    import urllib3
    sys.modules['%s.urllib3' % __name__] = urllib3

try:
    from . import chardet
except ImportError:
    import chardet
    sys.modules['%s.chardet' % __name__] = chardet
```

But PyInstaller doesn't seem to recognize it. Is there an option/hook to use this configuration?

I'm using:
Ubuntu Mate, 16.04.2 LTS
requests - 2.9.1 - installed through pip
Pyinstaller - 3.2.1 - compiled from source

This is a PyInstaller problem, not a Requests one. When you install Requests from pip, it comes with the packages subdirectory populated. If it's not being populated when you use PyInstaller, then PyInstaller has lost track of what code it needs. You'll need to take it up with the maintainers of PyInstaller.
OpenSSL issue when vendoring requests

I was trying to vendor requests in my own library. I used a similar vendoring structure as requests and I put requests under ceslib/packages
However, when I am trying to send a HTTPS request, I see the following error.
It seems like OpenSSL needs to be vendored by requests too?
Code Snippet:
```
import packages.requests as requests
self._session = requests.Session()
req = requests.Request('GET', 'https://www.google.com')
req = self._session.prepare_request(req)
response = self._session.send(req)
```

Error:
```Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/connectionpool.py", line 600, in urlopen
    chunked=chunked)
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/connectionpool.py", line 345, in _make_request
    self._validate_conn(conn)
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/connectionpool.py", line 844, in _validate_conn
    conn.connect()
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/connection.py", line 326, in connect
    ssl_context=context)
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/util/ssl_.py", line 308, in ssl_wrap_socket
    context.load_verify_locations(ca_certs, ca_cert_dir)
  File "/usr/lib/python2.7/site-packages/ceslib/packages/requests/packages/urllib3/contrib/pyopenssl.py", line 411, in load_verify_locations
    self._ctx.load_verify_locations(cafile, capath)
  File "/usr/lib/python2.7/site-packages/OpenSSL/SSL.py", line 525, in load_verify_locations
    _raise_current_error()
  File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 48, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.SSL.Error: [('system library', 'fopen', 'No such file or directory'), ('BIO routines', 'BIO_new_file', 'no such file'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]```

Nope, you aren't missing OpenSSL, you're missing the certs bundle `cacerts.pem` in the requests code directory. Looks like you misplaced it in your vendoring.

Thank you. Was able to solve this problem by updating the vendored version from 2.13.0 to 2.14.2
requests.exceptions.SSLError.__str__ returns non-string type

requests 2.4.3
python 2.7.9
os: Debian Jesse

I looked through the release notes from 2.4.3 to present and didn't see this one as fixed.

Issue:
requests.exceptions.SSLError is raised, but when the error is printed or cast to string, another error is thrown stating that __str__ returned a non-string.

Just to restate: the non-string value is the issue here. I'm not yet sure how to reproduce as we were doing some wacky things. If I'm successful in reproducing this, I'll follow-up with steps.

I was using python/requests to troubleshoot a 'connection reset by peer' error at work and we made the following manipulations:
- changed `/etc/hosts` to point a domain at a test IP.
- added a 'Host' header that referred back at that domain.
- hit an HTTPS/SSL URL on that domain
-- because of previous changes, the cert and domain likely mismatch
-- This URL does a 302 redirect (it's a redirect service)
- requests.exceptions.SSLError is raised and caught as expected
- printing the error and casting the error as `str()` raises an error about __str__ returning a non-string.
- iirc, this issue still existed when I set `verify=False`

Before reporting this issue to us, can you please report to the Debian maintainers? We are no longer providing support for 2.4.3, so unless it can be reproduced on the current release we're not really able to do much for you. However, the Debian maintainers from whom you installed the package *are* supporting that version of the software, so contacting them is more likely to be useful for you.

I should note, per the [Debian bug reporting notes](https://www.debian.org/Bugs/Reporting), that you should refrain from reporting bugs to the upstream maintainers:

> **Don't file bugs upstream**
>
> If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

Thanks for reaching out!
Cookies not passed to redirect

If I: 
  `requests.post(LOGIN_URL, data=DATA, headers=HEADERS)`

and the initial response is a redirect with with new cookies in the response, it seems the cookies are passed to the redirected request and the above may receive no cookies. :-(

If I do
  `requests.post(LOGIN_URL, data=DATA, headers=HEADERS, allow_redirects=False)`
then I do get back cookies, but then have to extract the cookie, and add them to a new request for the redirected URL.

If the redirect is to the same domain, it would be helpful to have the returned cookies passed to the second request where `allow_redirects=True`, emulating a browser's treatment of cookies.

Sorry, I need some more information. Requests absolutely *does* persist cookies like a browser does. Where are your cookies coming from? Are you setting them in the headers, or is the server setting them?

This is the behavior for 2.14.2

Without redirects:
```
   r = requests.post(LOGIN_URL, data=DATA, headers=HEADERS, allow_redirects=False)
   r.cookies  # is not empty
```

With redirects:
```
   r = requests.post(LOGIN_URL, data=DATA, headers=HEADERS, allow_redirects=False)
   r.cookies  # is empty
```

HEADERS doesn't have any cookies (or any fields that are reserved by http).
I didn't supply the cookies, they are returned from the request.

I think the sequence of events is as follows:

- Request: post LOGIN_URL (with form data, and boring headers, no cookies)
  Response: 
     has a set-cookie
     Is a 302 with location='/'
  
- Request: get with path='/' (and same domain), supply cookie
  Reponse: 200, but no set-cookie is returned from this final response.

Only the final response requests.post is returned -- this doesn't have any cookies from the login response as I'd hoped.

Looking at the implementation of  requests.post I see I can get what I want with:
```
with sessions.Session() as session:
    r = session.request(url=LOGIN_URL,
                        method="post",
                        data=LOGIN_FORMDATA,
                        headers=LOGIN_HEADERS)
  return r, session.cookies
```

I'd would be nice to be able to collect the final response and the collected session cookies in a single command. However, thinking about it, it probably wouldn't help the request API -- is probably better to use the session object to do what I want.
remove old test_requests.py listing from MANIFEST.in

This is a trivial fix to address a warning pointed out in #4012.

`test_requests.py` was moved from the top level directory into the `tests` directory in 2.10.0 but the MANIFEST.in wasn't updated afterwards. Installing from setup.py produces a warning (`no files found matching 'test_requests.py'`). This patch will remove the unneeded listing and keep the warning from cluttering stderr.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4015   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1940     1940           
=======================================
  Hits         1741     1741           
  Misses        199      199
```



------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/4015?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/kennethreitz/requests/pull/4015?src=pr&el=footer). Last update [e4693eb...f4b9082](https://codecov.io/gh/kennethreitz/requests/pull/4015?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
Remove range operators from markers.

Resolves #4013.

It turns out that older setuptools were pretty stupid and couldn't handle range operators, but they *can* handle parentheses and the word "or". So let's do that instead.

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

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

```diff
@@           Coverage Diff           @@
##           master    #4014   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files          15       15           
  Lines        1940     1940           
=======================================
  Hits         1741     1741           
  Misses        199      199
```



------

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


Cool, ok. Let's ship a 2.14.2 with this and see if this cleans up the last few lingering pain points.
Amazon Linux easy_install incompatible with 2.14.1

I've been following #4006 #4012 and I'm aware the guidance is to update to a newer pip, and that easy_install is not supported. I just wanted to make the case that not all of us have a choice on python package manager.

Take my case - I'm using Amazon Linux bootstrapped by Amazon CloudFormation. We give the CloudFormation initializer code (cfn-init for short) a list of python packages to install, and it installs them in any order it wants, using any mechanism it wants. Studying the logs, it looks like under the hood it's using easy_install.

I'm not even trying to install requests. I'm getting a floating version of it transitively through trying to install docker-py. So I see:

`[ERROR] easy_install failed. Output: Searching for docker-py==1.7.2`
...
`Searching for requests>=2.5.2`
...
`Best match: requests 2.14.1`
...
```
Running requests-2.14.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-wfkGhb/requests-2.14.1/egg-dist-tmp-H3aUMy
error: Setup script exited with error in requests setup command: Invalid environment marker: sys_platform == "win32" and python_version<"3.3"
```

Version information:
Amazon Linux AMI release 2016.09
Python 2.7.12
```
easy_install --version
setuptools 12.2
```


So at the moment I have a cumbersome workaround where I run cfn-init in two phases, first where I expressly install requests 2.13.0, then next where I install docker-py and it's happy with the requests already installed. But I just wanted to raise awareness that there is a category of people who are seeing this error through transitive use of requests (I didn't even know we were using it) and for which upgrading or changing package managers is non-trivial.


@jfwarner Thanks for this report.

Is it not possible to [upgrade the version of setuptools before you run cloudformation](https://gist.github.com/kixorz/10194688)? That will likely resolve your issue.

Unfortunately setuptools 12.2 is the latest and greatest available from Amazon Linux's yum repo.

```
yum update python27-setuptools
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main
amzn-updates
No packages marked for update
```

```
yum info python27-setuptools
Loaded plugins: priorities, update-motd, upgrade-helper
Installed Packages
Name        : python27-setuptools
Arch        : noarch
Version     : 12.2
Release     : 1.32.amzn1
Size        : 1.9 M
Repo        : installed
```

Gah, that's pretty frustrating. This seems to be down to setuptools 12 not knowing how to use range operators in markers. We can probably fix it though. See #4014.

Thanks - I know it's our own fault for not locking down all our transitive dependencies, but this is causing us a production outage on the ability to boot new servers. 

Confirmed that the issue has been resolved in 2.14.2 - thanks!

No problem, glad we could help!
Invalid environment marker

requests 2.14+ centos7 py27

```
omeroweb_1  |   Running setup.py egg_info for package requests
omeroweb_1  |     error in requests setup command: Invalid environment marker: platform_system == "Windows" and python_version<"3.3"
omeroweb_1  |     Complete output from command python setup.py egg_info:
omeroweb_1  |     error in requests setup command: Invalid environment marker: platform_system == "Windows" and python_version<"3.3"
```

Are you sure you receive the exact same output for 2.14 and 2.14.1? Because this appears to be a duplicate of #4006, which should have been resolved by #4007 in 2.14.1.

yes because https://github.com/ome/omero-mapr/blob/master/requirements.txt#L1

I have to `requests==2.13.0`

@aleksandra-tarkowska When are you encountering the error. Right now?

What version of pip are you using to install requests? What version of setuptools is currently installed?

yes, at the moment, it is new container

```
omeroweb_1  | Downloading/unpacking requests==2.14.1 (from omero-mapr==0.1.14->-r /home/omero/requirements-webapps.txt (line 2))
omeroweb_1  |   Running setup.py egg_info for package requests
omeroweb_1  |     error in requests setup command: Invalid environment marker: sys_platform == "win32" and python_version<"3.3"
omeroweb_1  |     Complete output from command python setup.py egg_info:
omeroweb_1  |     error in requests setup command: Invalid environment marker: sys_platform == "win32" and python_version<"3.3"
omeroweb_1  | 
```

CentOS 7
```
[omero@496158a7ba55 ~]$ easy_install --version
setuptools 0.9.8
[omero@496158a7ba55 ~]$ pip --version
pip 8.1.2 from /usr/lib/python2.7/site-packages (python 2.7)
```

default rpm provided by yum

Ok, so I think your setuptools is too old and unsupported by Requests. Try doing `pip install -U setuptools`: that should resolve your issue. This is a duplicate of #4006.

I agree. This is a duplicate of #4006. I'll also add that it appears that you're using easy_install to install requests. That may have worked even recently but has not been supported for *years*. Please use pip to install requests.

I'm running into this on Travis. Installing 'requests' fails since today with:
```
error: Setup script exited with error in requests setup command: Invalid environment marker: sys_platform == "win32" and python_version<"3.3"
```
I am confused since this job is running on Linux with Python 3.4.

Job URL: https://travis-ci.org/remram44/usagestats/jobs/230593204

@remram44 Try again, we shipped a 2.14.2 release that should have resolved your issue.

👍 
```
  Running setup.py install for requests
    
    warning: no files found matching 'test_requests.py'
Successfully installed omero-mapr requests
```

New build passed, thanks for the quick turnaround!
Install fails 2.14.x

The pypi page is not loading as well:
https://pypi.python.org/pypi/requests/2.14.1

Logs:
07:58:51 Processing requests-2.14.1.tar.gz
07:58:51 Writing /tmp/easy_install-WACg1D/requests-2.14.1/setup.cfg
07:58:51 Running requests-2.14.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-WACg1D/requests-2.14.1/egg-dist-tmp-MeAs3M
07:58:51 
07:58:51 stderr: no previously-included directories found matching 'docs/_build'
07:58:51 warning: no previously-included files matching '*.py[cdo]' found anywhere in distribution
07:58:51 warning: no previously-included files matching '__pycache__' found anywhere in distribution
07:58:51 warning: no previously-included files matching '*.so' found anywhere in distribution
07:58:51 warning: no previously-included files matching '*.pyd' found anywhere in distribution
07:58:51 zip_safe flag not set; analyzing archive contents...
07:58:51 error: Setup script exited with error in requests setup command: Invalid environment marker: sys_platform == "win32" and python_version<"3.3"

Thanks, I think this is an issue with your system. What OS are you running, and can you print out the version of pip you have installed please? This is almost certainly related to #4006.

@Lukasa I just checked our Jenkins/Ansible setup, we're running `easy_install cloudmonkey` that depends on requests: https://github.com/apache/cloudstack-cloudmonkey/blob/5.3.3/setup.py#L36
The OS is CentOS7.1.

The pypi page used to render correctly for old versions: 
https://pypi.python.org/pypi/requests/2.13.0

But not for the latest:
https://pypi.python.org/pypi/requests/2.14.1

This looks like broke it for me: https://github.com/kennethreitz/requests/commit/800a074b5d7adbbcaf96a5e6b3754c560f6768ff

Requests does not support being installed via `easy_install`. Have you tried running `pip install cloudmonkey`?

@Lukasa okay will amend changes, looks like the failure happens when `sys_platform` is not defined,  pip install --upgrade distribute may fix it.

Thanks @Lukasa for your support, using pip fixed the issue for me. Though bear in mind, our scripts used to work well with requests `1.13.0`, so something has changed.
I'll close the ticket now.

See the discussion in #4006 for an idea of what has changed.
[2.14.0] NameError: name 'platform_system' is not defined for pip 6.0.7 

Travis use `pip 6.0.7`
Today we had the following error:
```python
pip install -U requests==2.14.0

Using cached requests-2.14.0-py2.py3-none-any.whl
  Exception:
  Traceback (most recent call last):
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/basecommand.py", line 232, in main
      status = self.run(options, args)
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/commands/install.py", line 339, in run
      requirement_set.prepare_files(finder)
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/req/req_set.py", line 436, in prepare_files
      req_to_install.extras):
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2496, in requires
      dm = self._dep_map
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2697, in _dep_map
      self.__dep_map = self._compute_dependencies()
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2730, in _compute_dependencies
      common = frozenset(reqs_for_extra(None))
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py", line 2727, in reqs_for_extra
      if req.marker_fn(override={'extra':extra}):
    File "/home/travis/virtualenv/python2.7_with_system_site_packages/local/lib/python2.7/site-packages/pip/_vendor/_markerlib/markers.py", line 113, in marker_fn
      return eval(compiled_marker, environment)
    File "<environment marker>", line 1, in <module>
  NameError: name 'platform_system' is not defined
```

We can fix it using:
`pip install -U pip`
`# Successfully installed pip-9.0.1`

But maybe too much travis build use default pip version
Could be dual compatibility this requests package?

We had a similar fix for pylint: https://github.com/PyCQA/astroid/pull/360 based on https://github.com/pypa/packaging/issues/72

Thanks, this is a duplicate of #4006. See that issue for more discussion.