Raibek/requests-github-issues huggingface dataset:
test_HTTP_302_ALLOW_REDIRECT_POST fails

requests-1.0.4 introduced new test (RequestsTestCase.test_HTTP_302_ALLOW_REDIRECT_POST), which fails with all versions of Python.

```
$ python2.7 test_requests.py -v
test_BASICAUTH_TUPLE_HTTP_200_OK_GET (__main__.RequestsTestCase) ... ok
test_DIGESTAUTH_WRONG_HTTP_401_GET (__main__.RequestsTestCase) ... ok
test_DIGEST_HTTP_200_OK_GET (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_GET (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_GET_ALTERNATIVE (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_GET_WITH_MIXED_PARAMS (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_GET_WITH_PARAMS (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_HEAD (__main__.RequestsTestCase) ... ok
test_HTTP_200_OK_PUT (__main__.RequestsTestCase) ... ok
test_HTTP_302_ALLOW_REDIRECT_GET (__main__.RequestsTestCase) ... ok
test_HTTP_302_ALLOW_REDIRECT_POST (__main__.RequestsTestCase) ... FAIL
test_POSTBIN_GET_POST_FILES (__main__.RequestsTestCase) ... ok
test_POSTBIN_GET_POST_FILES_WITH_DATA (__main__.RequestsTestCase) ... ok
test_assertion (__main__.RequestsTestCase) ... ok
test_basic_building (__main__.RequestsTestCase) ... ok
test_decompress_gzip (__main__.RequestsTestCase) ... ok
test_different_encodings_dont_break_post (__main__.RequestsTestCase) ... ok
test_entry_points (__main__.RequestsTestCase) ... ok
test_invalid_url (__main__.RequestsTestCase) ... ok
test_params_are_added_before_fragment (__main__.RequestsTestCase) ... ok
test_path_is_not_double_encoded (__main__.RequestsTestCase) ... ok
test_request_ok_set (__main__.RequestsTestCase) ... ok
test_status_raising (__main__.RequestsTestCase) ... ok
test_unicode_get (__main__.RequestsTestCase) ... ok
test_urlencoded_get_query_multivalued_param (__main__.RequestsTestCase) ... ok
test_user_agent_transfers (__main__.RequestsTestCase) ... ok

======================================================================
FAIL: test_HTTP_302_ALLOW_REDIRECT_POST (__main__.RequestsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_requests.py", line 91, in test_HTTP_302_ALLOW_REDIRECT_POST
    self.assertEqual(r.status_code, 200)
AssertionError: 405 != 200

----------------------------------------------------------------------
Ran 26 tests in 12.686s

FAILED (failures=1)
```


Yep.


Intentional.


Do you plan to fix it somewhen?


It's not an issue with requests, it's an issue with the server that we're testing against. The test needs to be removed.
Allow configuring connection pool params for a session's adapters

The HTTPAdapter's initialisation code takes two optional parameters, pool_connections and pool_maxsize. The Session, however, doesn't ever use these when creating its HTTP adapters. It would be helpful to be able to influence these parameters when working with a session instead of relying on the DEFAULT_POOLSIZE value.


The intended action is for you to create a new instance of the HTTPAdapter and mount it to the session.
adapter for dataurl

adapter is a great feature, and i try to add this adapter for [dataurl](http://tools.ietf.org/html/rfc2397).

but the interface of adapter has some problem:
- the interface is only suit to HTTPAdapter with urllib3
- some modal like Response.close is depend on urllib3, it's hard to change a backend just with an adapter.
- Request.prepare() did so much for other scheme, maybe.

requests is great, i would like with requests with tornado.AsyncHTTPClient long time ago, maybe adapter is the best way......


Close can simply do nothing.


I don't agree with any of your points, but I appreciate your feedback.

I won't be merging this because there's obviously no need for this in the codebase. This looks pretty awesome though! You should make a module for it :)
Provide full URL to proxies.

This resolves #1056 and #1058.


I couldn't think of a good reproducible way to test this, but I'm open to ideas.


This is how you could reproduce it.

Set up a proxy (this one is very useful for debugging):

```
pip install mitmproxy
```

Run it:

```
mitmproxy -a 127.0.0.1 
```

Then dispatch a request using requests:

```
import requests

s = requests.session()

s.proxies = {
    'http':  '127.0.0.1:8080',
    'https': '127.0.0.1:8080',
}

s.get('http://google.de')
s.get('https://google.de', verify=False)
```

The current release results in error 400 (malformed request).


Bit much to ask of someone running the test suite though, surely?


Agreed @lukasa


You could use the test server introduced in https://github.com/kennethreitz/requests/pull/982


Rebased to allow automerging. =)


Looks good to me!
HTTP Proxies broken

The HTTP proxy support in the current release (1.0.3) is broken.

A valid request sent to the proxy would be:

```
GET http://google.de/ HTTP/1.1\r\n-
```

Requests, however, does this:

```
GET / HTTP/1.1\r\n-
```

Obviously, this won't work. Previous versions (0.14, for example) are not affected.


Duplicate #1056


@sigmavirus24 is right. I've just posted a possible fix in #1056, so please follow the discussion there. Thanks for the report!
Session constructor does not take headers nor auth as parameters

Documentation of 1.0.0 (http://docs.python-requests.org/en/v1.0.0/user/advanced/) says
`requests.session(auth=auth, headers=headers)` is a legitimate statement.

However, reading the code I see that session(), nor Session.**init** do not take any arguments.
https://github.com/kennethreitz/requests/blob/master/requests/sessions.py

So if I have not misread anything, the docs should be fixed demonstrating the way to set persistent session-specific headers, auth etc.


This is a duplicate of #1034 and rejected patch #1039 which might be used as an example to work around this.


Yeah, the docs are wrong. I've been meaning to change it for ages, but my life keeps getting in the way. I should have a PR for this today though.
Proxy

![ ](https://f.cloud.github.com/assets/3097956/27000/6b5f71fa-4b67-11e2-914d-7afec0cc9fab.png)


![ ](https://f.cloud.github.com/assets/3097956/27020/97a4ec7a-4b69-11e2-89b1-d1c051803e62.png)


The second problem is easy: as of Requests v1.0.0, `requests.Session()` does not take arguments in its constructor.


import requests as http

s = http.Session()
s.proxies = {'http': '127.0.0.1:8888'}

And so works.


Yup, this is a duplicate of #997.

Edit for clarity:

Try:

``` python
import requests

requests.get('http://google.ru', proxies={'http': 'http://127.0.0.1:8888'})
```


![ ](https://f.cloud.github.com/assets/3097956/27056/a40c36a6-4b6b-11e2-8144-d4f5ae555e4d.png)

:(


Header "Host" must equal "google.ru"


So, I've got a branch with a possible fix for this issue [here](https://github.com/Lukasa/requests/tree/proxy). @python273 and @leoluk, would you like to try downloading it and making the same request? If it works, I'll submit a Pull Request.


Sure. Works fine now, both HTTP and HTTPS.


Awesome, thanks for that. =)


Resolved by #1060.
Correctly identify certificate filenames.

Resolves issue #1046.

I have not tested this, so...yeah.


basestring doesn't exist in python 3


Wasn't basestring in compat?


Yeah, need to import it.


@Lukasa  import it :) 


C'mon @Lukasa you need some sleep brother.


I need a holiday. Got a week off on Friday though, that'll help!


@Lukasa take a break from everything, you deserve it. :fistbump:


@kennethreitz, what's the state of this? Got `basestring` in now, so all should be good. =)


Merged :)
potential cert bug

This code in adapters.py

``` python
if cert:
   if len(cert) == 2:
       conn.cert_file = cert[0]
       conn.key_file = cert[1]
    else:
        conn.cert_file = cert
```

Would fail erroneously if a the cert file name were two characters long.
Safer would be to test if cert is a string
such as

``` python
if cert:
  if hasattr(cert, 'strip'):
     conn.cert_file = cert
  else:
     conn.cert_file = cert[0]
     conn.key_file = cert[1]
```


Nice catch 

Samuel Smith notifications@github.com wrote:

> This code in adapters.py
> 
> if cert:
>            if len(cert) == 2:
>                conn.cert_file = cert[0]
>                conn.key_file = cert[1]
>            else:
>                conn.cert_file = cert
> 
> Would fail erroneously if a the cert file name were two characters
> long.
> Safer would be to test if cert is a string
> such as
> 
> if cert:
>  if hasattr(cert, 'strip'):
>     conn.cert_file = cert
>  else:
>     conn.cert_file = cert[0]
>     conn.key_file = cert[1]
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1046


Happy to help. Really like the direction Requests is headed in.


Thanks for reporting this! This has been resolved by #1049.
#1043: redirect POST data upon POST redirect

Is there a simpler way to say: "this pull request solves issue X"? I hope putting it's number in the title links them together.


It doesn't, but this does: #1043.


I removed this intentionally. Why would you want to do that?


I don't think this is a bug. We follow POST redirects with a GET, like a web browser does.


"Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request."

from: http://tools.ietf.org/html/rfc2616

And FYI: because of these ambiguities two new redirect codes we're added: 303 and 307 for indicating whether the request should change to a GET or stay as it was respectively.


@alonho 
This spec is soon to be obsolete by new version - see http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0103.html

[7.4.2 301 Moved Permanently](http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-7.4.2)

> Note: For historic reasons, user agents MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary Redirect) can be used instead.

See issue #269 where this topic was discussed.


Yes, I had spec-compliant behavior for a long time, but eventually gave in.

If you don't want this behavior, simply `allow_redirects=False`
new api to sessions breaks old code, even official documentation is broke (duplicate of #1040)

Please don't make this bug a WONTFIX because it breaks at least one library out there that are dependent on the old sessions API.


V1.0.0 is an API breaking change. This is intentional. The 3rd party library can remain on v0.14.2 if it cannot be rewritten.


This is not a bug. Release 1.0 is not backwards compatible.


Will you at least indicate these differences in the online documentation? It's definitely not readily visible.


Absolutely.


Duplicate of #1034 and rejected patch #1039 which might be used as an example to work around this.
TypeError in requests.session() when using auth

Hello,

Cant create session with auth object after upgrading to 1.0.3 used to work in 0.14.2
(This is an interactive session, I replaced < and > with //)

Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

> import requests
> requests.**version**
> '1.0.3'
> 
> auth = requests.auth.HTTPDigestAuth('admin','1234')
> auth
>  //requests.auth.HTTPDigestAuth object at 0xb715c9ec//
> 
> requests.session(auth=auth)
> Traceback (most recent call last):
>   File "//stdin//", line 1, in //module//
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 385, in session
>     return Session(**kwargs)
> TypeError: **init**() got an unexpected keyword argument 'auth'
> 
> requests.session()
> //requests.sessions.Session object at 0xb715c9cc//
> 
> auth=('user', 'pass')
> auth
> ('user', 'pass')
> 
> requests.session(auth=auth)
> Traceback (most recent call last):
>   File "//stdin//", line 1, in //module//
>   File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 385, in session
>     return Session(**kwargs)
> TypeError: **init**() got an unexpected keyword argument 'auth'


`session()` no longer takes parameters in its constructor. Replace the code with:

``` python
auth = requests.auth.HTTPDigestAuth('admin', '1234')
s = requests.session()
s.auth = auth
```


That was fast. Thank you!!!


```
s = requests.Session()
s.auth = requests.auth.HTTPDigestAuth('admin', '1234')
```


Duplicate of #1034 and rejected patch #1039.
Fix #1036

I can only assume that the only possible thing to close on a session are the
adapters. As such, I wrote the close method for a session object which closes
all possible adapters.


+1, let's also add a `passing`close` method to the base adapter


Instead of raising `NotImplementedError`?


We could do that. My thought was that some connection adapters won't need to close.


I'm still unsure what you meant, sorry.


nevermind, it's fine as-is :)
session as context manager does not work properly

```
s = requests.session()
with s:
    print s
```

This gives: AttributeError: 'Session' object has no attribute 'close'

I see in the code that it does self.close() but there is no such method.

My guess is that it is supposed to call something like:

```
for adapter in self.adapters.itervalues():
    adapter.close()
```

but i'm not sure about thread-safety of this approach...


This is fixed now
Broken cookies persistence in version 1.0.2

I've just updated from 0.14.2 to 1.0.2 and got broken code, which is depended on cookies persistence.

```
session = requests.session()
response = session.get('http://example.com/page-1')
print 'Request 1'    
print response.request.headers
print '------------------------------------------------'
response = session.get('http://example.com/page-2')
print 'Request 2'    
print response.request.headers
print '------------------------------------------------'
```

In version 0.14.2 I got:

```
Request 1
{'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/0.14.2 CPython/2.7.3 Linux/3.2.0-34-amd64'}
------------------------------------------------
Request 2
{'Cookie': '...', 'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/0.14.2 CPython/2.7.3 Linux/3.2.0-34-amd64'}
------------------------------------------------
```

But in version 1.0.2 output is:

```
Request 1
{'Content-Length': '0', 'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/1.0.2 CPython/2.7.3 Linux/3.2.0-34-amd64'}
------------------------------------------------
Request 2
{'Content-Length': '0', 'Accept-Encoding': 'gzip, deflate, compress', 'Accept': '*/*', 'User-Agent': 'python-requests/1.0.2 CPython/2.7.3 Linux/3.2.0-34-amd64'}
```


This has been fixed but the fix hasn't been released yet


Actually I may have spoken too soon. Looks like @kennethreitz just tagged v1.0.3 which means it is probably on PyPI. Try doing `pip install -U requests` and let us know if this is resolved (which it should be).


Yep, It's fixed. Thanks guys!
restore old certificate bundle behavior

Since a CA bundle started being vendored inside Requests, it always
overrides the OS bundle. This changes the preference order to be
packaged certifi, then the OS bundle, then the vendored bundle,
allowing managed environments to use their system bundles by simply
omitting a certifi package.

References: #557


This will cause bugs for many users. I'd rather just provide a nice documented way for them to disable the built in one.


Hmm, something went wrong. I'll fix this up and make a new pull request (it doesn't seem to like the rebase either).
restore test coverage post-1.x

It looks like a lot of tests didn't make it into 1.x, in particular, the cookie tests in `tests/test_cookies.py`. Compare #1027.


The test suite was something I hated. It was overly complex. I'm much happier with the new one.

Let's keep adding things into test_requests.py


Cool, I'll plan to send pull requests adding back some of the removed tests.
Since 1.0, seeing a large amount of "Cannot assign requested address" socket.errors

 (Caused by <class 'socket.error'>: [Errno 99] Cannot assign requested address)

ConnectionError(MaxRetryError("HTTPConnectionPool(host='foo', port=80): Max retries exceeded with url: /path (Caused by <class 'socket.error'>: [Errno 99] Cannot assign requested address)",),)

I do not have this behavior on boxes that have not upgraded and are making the same GET requests.


I've not been able to create a reproducible test case for this that I can export.  I did find a upstream bug in my code due to it though where things that were supposed to be memoized were not.

On a side note, with the removal of the requests.default class, all that 1.0 has for impacting pool size is changing the constants which seems a bit hacky.


@gmr if you think it is the pool size, try subclassing the `HTTPAdapter`, e.g.,

``` python
from requests.adapters import HTTPAdapter


class GMRAdapter(HTTPAdapter):
    def __init__(self):
        super(GMRAdapter, self).__init__(GMR_CONNECTIONS_SIZE, GMR_POOL_SIZE)


session.adapters['http'] = GMRAdapter()
session.adapters['https'] = GMRAdapter()
```

**Edit** where session above is a `Session` instance that you've already created.


I did bump the pool size and combined with my fix (to the upstream caching code), that addressed my issue. I'll keep the adapter subclassing in mind.  Thanks!


Hmm, I don't think the defaults changed. Should we change the defaults?


Sorry I was not more clear. I meant you removed the API (requests.defaults) for setting those values.


Ah, correct. This was intentional.


Also, I forgot session objects now have the `mount` method, i.e.

``` python
session.mount('http://', GMRAdapter())
session.mount('https://', GMRAdapter())
```


+1
Requests 1.0.2 + Broken JSON

Yo!

`response.json` no longer works in requests 1.0.2, instead you must call `response.json()` manually, which breaks a lot of library support.

Will this go back to the old way? If not, I'd be happy to update all my dependencies :o


In Kennith's [blog post](http://kennethreitz.com/announcing-requests-v100.html) today he wrote:

> Removal of the magic Response.json property. Replaced with a method.

I think this change is intended to stay.


I don't exactly know why it was changed to a method, but I'm guessing it won't 
be changed back.
On Mon, Dec 17, 2012 at 04:38:02PM -0800, Randall Degges wrote:

> Yo!
> 
> `response.json` no longer works in requests 1.0.2, instead you must call `response.json()` manually, which breaks a lot of library support.
> 
> Will this go back to the old way? If not, I'd be happy to update all my dependencies :o
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1028


And looking at the new json method, I like it. Attributes shouldn't raise exceptions realistically when accessed unless they don't exist. Making it a method and exposing a possible issue with loading the json makes far more sense than the way the old attribute worked.

@rdegges you won't be the only one updating your dependencies ;)


This is an extremely intentional change. Please read [semver](http://semver.org)


Yes, it was because you shouldn't get exceptions when accessing an attribute. The old API was wrong.


Yep, I hadn't really dug into the code. But this makes far more sense.


Just weighing in as I only noticed this change today. First, @kennethreitz, I totally agree with your reasons for changing it and I'm glad you did! This is a good upgrade.

That said, I might have preferred a staged transition, like:

v 0.15.0:
- `response.json` is renamed to `response.json_property`
- `response.json_method` is the method version of `response.json_property`
- `response.json` is a new property that issues a DeprecationWarning and returns `response.json_property`

End user actions: replace `response.json` with `response.json_property` throughout their code. Other co-installed projects designed for 0.14.1 can keep using `response.json` for now. Installations can upgrade from 0.14.1 to 0.15.0 without breakage.

v 1.0.0:
- `response.json` now points to `response.json_method`

End user actions: replace `response.json_property` with `response.json()` throughout their code. Other co-installed projects designed for 0.15.0 can keep using `response.json_property` for now. Installations can upgrade from 0.15.0 to 1.0.0 without breakage.

v 1.1.0:
- `response.json_property` and `response.json_method` are removed

I find myself in the situation where it's easy enough to upgrade the code I'm writing to use the 1.0.0 API (which I think is great!), but I have to coordinate with other departments so that we all make the from from 0.14.1 to 1.0.0 at the same moment. There's no intermediate state that supports both the old and new styles at the same time.


good info
Requests 1.0.2 doesn't appear to set session cookies on POST requests

I can confirm that the example using httpbin.org still works. However, my similar code that sends a POST request (to login) the response object contains the cookie, however the session object is not updated to contain the cookie thus making the session useless unless I manually do the following for POST requests:

```
session.cookies = response.cookies
```

What's also odd is in the httpbin.org example using the `GET` request, while the session's cookies are updated, the response's cookie attribute is empty:

```
>>> import requests
>>> s = requests.session()
>>> r = s.get('http://httpbin.org/cookies/set/sessioncookie/123456789')
>>> s.cookies
<<class 'requests.cookies.RequestsCookieJar'>[Cookie(version=0, name='sessioncookie', value='123456789', port=None, port_specified=False, domain='httpbin.org', domain_specified=False, domain_initial_dot=False, path='/', path_specified=True, secure=False, expires=None, discard=True, comment=None, comment_url=None, rest={}, rfc2109=False)]>
>>> r.cookies
<<class 'requests.cookies.RequestsCookieJar'>[]>
```


Discovered the problem- cookies are only persisted when a `location` header is present. The sites I am logging into do not send location headers upon login.
New urrlib3 breaks App Engine

The following import in urllib3/util.py cannot take place

``` python
from ssl import wrap_socket, CERT_NONE, SSLError, PROTOCOL_SSLv23
```

So we have an exception at line 293

``` python
def ssl_wrap_socket(sock, keyfile=None, certfile=None, cert_reqs=CERT_NONE,
                        ca_certs=None, server_hostname=None,
                        ssl_version=PROTOCOL_SSLv23):
        return wrap_socket(sock, keyfile=keyfile, certfile=certfile,
                           ca_certs=ca_certs, cert_reqs=cert_reqs,
                           ssl_version=ssl_version)
```

App engine dies with NameError: name 'CERT_NONE' is not defined


See @kennethreitz's comment here: https://github.com/kennethreitz/requests/issues/1008


Does it work with `cert_reqs=None`?
I have a patch in the pipeline which could be modified to make it work this way.
Sry for breaking it.


So @sigmavirus24 it seems that GAE support is deprecated :(


If this is your only problem try to use urllib3 from https://github.com/t-8ch/urllib3/tree/unify_ssl_api
(current master + some commits)


urllib3 still strives to maintain GAE support, so feel free to open a bug in our part of the land and we can deal with it there. :)


Thanks @shazow , I ll try to patch it first!
Proxies are not working in v1.0

Whenever I am trying to send a request using proxies, I get the following error.

AttributeError: 'PoolManager' object has no attribute 'ProxyManager'

I am running the following command

```
r = requests.get("http://google.com",  proxies={"http": "127.0.0.1:8128", "https": "127.0.0.1:8128"}, timeout=100)
```

``` python
/Library/Python/2.7/site-packages/requests/api.pyc in request(method, url, **kwargs)
     36 
     37     session = sessions.Session()
---> 38     return session.request(method=method, url=url, **kwargs)
     39 
     40 

/Library/Python/2.7/site-packages/requests/sessions.pyc in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert)
    254 
    255         # Send the request.
--> 256         resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
    257 
    258         # Redirect resolving generator.

/Library/Python/2.7/site-packages/requests/sessions.pyc in send(self, request, **kwargs)
    345         """Send a given PreparedRequest."""
    346         adapter = self.get_adapter(url=request.url)
--> 347         r = adapter.send(request, **kwargs)
    348         return r
    349 

/Library/Python/2.7/site-packages/requests/adapters.pyc in send(self, request, stream, timeout, verify, cert, proxies)
    146         """Sends PreparedRequest object. Returns Response object."""
    147 
--> 148         conn = self.get_connection(request.url, proxies)
    149 
    150         self.cert_verify(conn, request.url, verify, cert)

/Library/Python/2.7/site-packages/requests/adapters.pyc in get_connection(self, url, proxies)
    128 
    129         if proxy:
--> 130             conn = self.poolmanager.ProxyManager(self.poolmanager.proxy_from_url(proxy))
    131         else:
    132             conn = self.poolmanager.connection_from_url(url)

AttributeError: 'PoolManager' object has no attribute 'ProxyManager'
```


Sorry for the bug! #1017


Should be better now!


@pankajn17 

How did you get this pretty stack with source context?


@piotr-dobrogost Python 3.


IPython does it too.
AttributeError: 'HTTPAdapter' object has no attribute 'verify'

``` python
certs = requests.utils.get_os_ca_bundle_path()
requests.get('https://google.com', verify=certs)

Traceback (most recent call last):
  File "<ipython-input-22-b57935839df3>", line 1, in <module>
    requests.get('https://google.com', verify=certs)
  File "./requests/api.py", line 49, in get
    return request('get', url, **kwargs)
  File "./requests/api.py", line 38, in request
    return session.request(method=method, url=url, **kwargs)
  File "./requests/sessions.py", line 256, in request
    resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
  File "./requests/sessions.py", line 347, in send
    r = adapter.send(request, **kwargs)
  File "./requests/adapters.py", line 150, in send
    self.cert_verify(conn, request.url, verify, cert)
  File "./requests/adapters.py", line 65, in cert_verify
    cert_loc = self.verify
AttributeError: 'HTTPAdapter' object has no attribute 'verify'

```

[Docs](http://docs.python-requests.org/en/v1.0.0/user/advanced/#ssl-cert-verification):

```
You can also pass verify the path to a CA_BUNDLE file for private certs.
You can also set the REQUESTS_CA_BUNDLE environment variable.
```


Oops, simple fix. Sorry about that.
PoolManager object has no attribute ProxyManager

Dear all, 

I want to use requests library (current master) behind a proxy and this is what i get:

```
debian:~# export http_proxy=http://192.168.1.1:3128
debian:~# python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.get("http://www.gr")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/.local/lib/python2.6/site-packages/requests/api.py", line 49, in get
    return request('get', url, **kwargs)
  File "/root/.local/lib/python2.6/site-packages/requests/api.py", line 38, in request
    return session.request(method=method, url=url, **kwargs)
  File "/root/.local/lib/python2.6/site-packages/requests/sessions.py", line 256, in request
    resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
  File "/root/.local/lib/python2.6/site-packages/requests/sessions.py", line 347, in send
    r = adapter.send(request, **kwargs)
  File "/root/.local/lib/python2.6/site-packages/requests/adapters.py", line 148, in send
    conn = self.get_connection(request.url, proxies)
  File "/root/.local/lib/python2.6/site-packages/requests/adapters.py", line 130, in get_connection
    conn = self.poolmanager.ProxyManager(self.poolmanager.proxy_from_url(proxy))
AttributeError: 'PoolManager' object has no attribute 'ProxyManager'
>>> requests.__version__
'1.0.0'
```


Yup, that looks wrong.

@kennethreitz, I haven't ramped up on the adaptors stuff yet, but it feels like [line 130 of adapters.py](https://github.com/kennethreitz/requests/blob/master/requests/adapters.py#L130) should read `conn = ProxyManager.(self.poolmanager.proxy_from_url(proxy))`. You'd need to import `ProxyManager` too.

If I get up to speed tonight I'll branch and raise a PR, but I thought I'd put this here as I might not.


all better!
OAuth1 with realm parameter

The OAuth1-wrapper included in requests doesn't include a parameter for oauth-parameter realm. I tried to add it as a regular post/get parameter but this leads to it being included in the base_string used to calculate the signature. This is not per spec.

The oauthlib.oauth1.rfc5849.Server excludes the realm parameter(even if received as a post/get parameter) so I get a signature mismatch.


OAuth is being moved to another module.


For the interested: [requests/requests-oauthlib](https://github.com/requests/requests-oauthlib).
raw interface no longer working?

I recently upgraded from Requests 0.11.1 to 0.14.2. I get a few scripts that rely on the library to download media files (couple of megabytes each). Before, this approach worked just fine:

```
import requests

r = requests.get('http://docs.python-requests.org/')

while True:
   print 'reading...'
   chunk = r.raw.read(64 * 1024)
   print 'got a chunk of %d bytes' % len(chunk)
   if len(chunk) == 0:
      break
```

Now, the first read() returns zero byte. Am I doing something wrong?


You have to add `prefetch=False` parameter
requests.session not persisting cookies

Hello,
I have tried the following sample code from http://docs.python-requests.org/en/latest/user/advanced/  with requests 0.14.2:

import requests
s = requests.session()
s.get('http://httpbin.org/cookies/set/sessioncookie/123456789')
r = s.get("http://httpbin.org/cookies")
print r.text

which yields the following output on wireshark http://imgur.com/a/aCwKN#0.
As you can see in the 3rd capture, the sessioncookie is not being sent and consequently the reply's content has no cookie data

Also this code:

import requests
r = requests.get("http://httpbin.org/cookies", cookies = {"sessioncookie":"123456789"})
print r.text

causes an error:

Traceback (most recent call last):
  File "C:\Users\geancarlo\Documents\Visual Studio 2010\Projects\woonro-vote\woo
nro-vote\test.py", line 2, in <module>
    r = requests.get("http://httpbin.org/cookies", cookies = {"sessioncookie":"1
23456789"})
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\api.py"
, line 60, in get
    return request('get', url, *_kwargs)
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\api.py"
, line 49, in request
    return session.request(method=method, url=url, *_kwargs)
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\session
s.py", line 165, in request
    prep = req.prepare()
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\models.
py", line 193, in prepare
    p.prepare_cookies(self.cookies)
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\models.
py", line 358, in prepare_cookies
    cookie_header = get_cookie_header(cookies, self)
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\cookies
.py", line 116, in get_cookie_header
    jar.add_cookie_header(r)
  File "C:\Python27\lib\cookielib.py", line 1324, in add_cookie_header
    cookies = self._cookies_for_request(request)
  File "C:\Python27\lib\cookielib.py", line 1250, in _cookies_for_request
    cookies.extend(self._cookies_for_domain(domain, request))
  File "C:\Python27\lib\cookielib.py", line 1230, in _cookies_for_domain
    if not self._policy.domain_return_ok(domain, request):
  File "C:\Python27\lib\cookielib.py", line 1147, in domain_return_ok
    req_host, erhn = eff_request_host(request)
  File "C:\Python27\lib\cookielib.py", line 604, in eff_request_host
    erhn = req_host = request_host(request)
  File "C:\Python27\lib\cookielib.py", line 589, in request_host
    url = request.get_full_url()
  File "C:\Python27\lib\site-packages\requests-0.14.2-py2.7.egg\requests\cookies
.py", line 51, in get_full_url
    return self._r.full_url
AttributeError: 'PreparedRequest' object has no attribute 'full_url'
Press any key to continue . . .


You aren't using requests v14.2, you're using the development version that is currently being rewritten.

Install with pip.
Install through pip fails under Python 3.3

Hey, sorry if I'm going about this in the wrong way, new to this.

I was attempting to install requests to a new virtualenv using python3 and pip. It failed with the following:

```
Downloading/unpacking git+https://github.com/kennethreitz/requests
  Cloning https://github.com/kennethreitz/requests to /var/folders/wz/jd2dflq52hbd0t48t3th34xw0000gn/T/pip-57zi3u-build
  Running setup.py egg_info for package from git+https://github.com/kennethreitz/requests
    Traceback (most recent call last):
      File "<string>", line 16, in <module>
      File "/var/folders/wz/jd2dflq52hbd0t48t3th34xw0000gn/T/pip-57zi3u-build/setup.py", line 6, in <module>
        import requests
      File "./requests/__init__.py", line 54, in <module>
        from .api import request, get, head, post, patch, put, delete, options
      File "./requests/api.py", line 14, in <module>
        from . import sessions
    ImportError: cannot import name sessions
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 16, in <module>

  File "/var/folders/wz/jd2dflq52hbd0t48t3th34xw0000gn/T/pip-57zi3u-build/setup.py", line 6, in <module>

    import requests

  File "./requests/__init__.py", line 54, in <module>

    from .api import request, get, head, post, patch, put, delete, options

  File "./requests/api.py", line 14, in <module>

    from . import sessions

ImportError: cannot import name sessions

----------------------------------------
Command python setup.py egg_info failed with error code 1 in /var/folders/wz/jd2dflq52hbd0t48t3th34xw0000gn/T/pip-57zi3u-build
```

When I tried the same with python 2.7.2 it worked fine and installed without any issues.

I modified api.py, line 22 from `from adapters import HTTPAdapter` to `from .adapters import HTTPAdapter` and it seemed to fix the problem when installing with python3. I also tried reinstalling into a new virtualenv using python 2.7.2 with the above change and it seemed to work fine.

I'm pretty much brand new to python, so the the above change could have more consequences than I'm aware of, but I just thought I'd let you know.

Thanks.


I'm getting the same thing when attempting to install from the repository (this). I've mirrored @harmesy's fix in a [pull request](https://github.com/kennethreitz/requests/pull/1011).


And, @harmesy, you went about this in a completely correct way. :+1: 


Closing since there was a pull request. Thanks again! :cake:
Auth documentation.

Thoughts? Not sure whether we want a separate section on the Requests org in general, but we can add that as a separate change if we do.


Well, I think I'd like to add a whole new page to the docs for authentication. I'd like the conanical usage docs to be here.


Cool, I'll try to get on this sometime this week. Sorry about disappearing over the weekend, it was manic. Stupid Christmas. :cake:


UNACCEPTABLE


But look, I got Requests a christmas tree and everything! IT HAS GIFTS UNDER IT!

:christmas_tree: 
:gift: :gift: :gift: 


Is this closer to what you wanted?

NB: I've got zero experience with Sphinx so this may not compile properly.


beautiful :)
Documentation


Document new logging.


Document porting to v1.0.0.


Work in progress.


The majority of breakages I see from 0.14.2 to 1.0.x is due to:
`TypeError: 'instancemethod' object has no attribute '__getitem__'`

Whenever I try to access response.json

So it's probably good to have this one highlighted in the porting doc?

Thanks :)


@woozyking that was in the notes for 1.0, json is now a method not an attribute, i.e., use `response.json()` instead of `response.json`


:+1: would be good to have a troubleshooting section


Whoops thought this was a bug report 9_9. But yeah, should be a transition section like @woozyking suggests.


@sigmavirus24 yep, I saw that. Just saying to highlight it in the porting doc :)


You're probably already aware, but I'd also like to point out that the configuration documentation is out of date: http://docs.python-requests.org/en/latest/api/#configurations


We are :)
requests.auth has an orphaned reference to ._oauth

Symptom:

```
Traceback (most recent call last):
  ...
  File "/Users/mlm/.virtualenvs/mlm/src/requests/requests/auth.py", line 68, in __init__
    self.client = Client(client_key, client_secret, resource_owner_key,
NameError: global name 'Client' is not defined
```

Using:

```
(mlm)
(mlm)(master) mlm@matt-mmf-macbook.local:~/.virtualenvs/mlm/src/requests
$ git show 
commit d74bd7e1a28eb80cd9dba1a0d149f35dd35ab3e0
Merge: a7344a0 500dc78
Author: Kenneth Reitz <me@kennethreitz.com>
Date:   Wed Dec 12 00:09:43 2012 -0800

    Merge pull request #998 from jamshid/master

    Issue #996 Location should not be followed unless 30X response

(mlm)
(mlm)(master) mlm@matt-mmf-macbook.local:~/.virtualenvs/mlm/src/requests
$ 
```


Enjoy your #1000 :sparkles: :beers: :sparkles:
Add "connection timeout" feature in addition to regular timeout.

Hi!

I'd like to suggest a new feature - two types of timeouts.
Regular one - happens when we wait for response from server on existing connection.
And a new one - connection timeout. Happens only when we try to create a new socket connection.
I added new request parameter connect_timeout and two new exceptions ConnectionTimeout and OperationTimeout.

But why anybody would need such a thing?

It can be useful when a call to some HTTP API takes a long time to answer the query (for ex. reading lots of data), but not so much to connect to the server.
With this new feature we can set bigger timeout and smaller connect_timeout, so network failures, dead API servers or DNS problems could be detected fast.

Other use case is - write request gone bad.
We connected to the server, called PUT to create some new record and caught timeout while waiting for response. Some async APIs work so that your request was actually processed despite broken connection.
And with two separate exceptions we can react differently in such a case - on ConnectionTimeout we know for sure nothing've been done so we can repeat the call. On OperationTimeout we may (or may not) poll the server for some indication that something is already going on and if not repeat the call.

On implementation:

I've implemented this feature in a way that does not break expected behavior for an existing code using the library.
New exceptions - ConnectionTimeout and OperationTimeout are subclasses of existing Timeout class.
Same goes for urllib3 TimeoutError and it's new subclasses.

New parameter connect_timeout is optional and when not given, value of the timeout parameter is used for both timeouts.
New HTTPConnectionTwo class (lame name, any suggestions?) takes one timeout in **init** method and then checks whether it's a single value or a pair, so it also can be initialized exactly like HTTPConnection.

And thank you so much for the great library!
## 

Pasha Kirichenko


Just read about feature freeze. Oops!

Should I close this one and reopen later or it can hang in here until time comes?


You'll almost certainly need a new PR when the refactor is finished as all of the internals will be different. =)

For the future, urllib3 is a vendored dependency that is maintained [here](https://github.com/shazow/urllib3). Any time you need to make a change in a urllib3 file it should be made in the mainline repository, not here.


My bad!
I close this request and will split the changes. urllib3 changes will go into it's main repo.

Thanks.


No need to apologise, it's not an inconvenience. =) Thanks for contributing!
Location header does not mean "redirect", only when response status is 30X

When using strict_mode (which should be the default, buggy browsers be damned) and a POST gets a 301 redirect, your library will correctly issue a POST to the uri pointed to by Location, but if _that_ response is a 201 with a Location header it will loop indefinitely until requests.exceptions.TooManyRedirects. 

``` python
# Fails if /foo/ responds with a 301 to /bar/, and that responds with a 201 with a Location header.
my_config = {'strict_mode': True, 'verbose': sys.stderr}
print requests.post('http://example.com/foo/', data='', allow_redirects=True, config=my_config)
```

This "while" test should only follow "Location" if the response code is a redirect. A Location header on a 201 response is perfectly valid, just end the request there. 

This seems like a correct fix:

``` python
--- orig-0.14.2/models.py   2012-11-30 22:44:13.000000000 +0000
+++ ./models.py 2012-12-11 22:26:41.000000000 +0000
@@ -232,7 +232,7 @@

         if r.status_code in REDIRECT_STATI and not self.redirect:

-            while (('location' in r.headers) and
+            while (('location' in r.headers and r.status_code in REDIRECT_STATI) and
                    ((r.status_code is codes.see_other) or (self.allow_redirects))):

                 r.content  # Consume socket so it can be released
```


Looks good to me. Want to open a Pull Request with the fix? =)


Sure, will figure out git and do it tomorrow.


Resolved by #996. Thanks a bunch! =D
Expose “source address” variable for users on 2.7 or 3.2+

In Python 2.7 and 3.2+ the ability to make a request from a particular source IP address was added to [httplib](http://docs.python.org/2/library/httplib.html#httplib.HTTPConnection) and [socket](http://docs.python.org/2/library/socket.html#socket.create_connection) closing Python [issue 3972](http://bugs.python.org/issue3972) which had previously been addressed by [Alex Martelli on SO](http://stackoverflow.com/questions/1150332/source-interface-with-python-and-urllib2). It would be great if the Requests API exposed this standard library functionality.


We could expose this in the refactor as a connection parameter.

@shazow, what would need to change in urllib3?


See https://github.com/shazow/urllib3/issues/9.

How do we feel about Py26 support these days?


I'd still like Py26 support, but I guess I can just upgrade to 2.7 on all my old machines that I use (except for those not under my control)


@shazow Last I checked, @kennethreitz's 'official' position was that we must support 2.7 and 3.3, and anything else is a bonus.


I still believe 2.6 falls under that umbrella too. Why wouldn't you just make this a feature that is unsupported on 2.6? 

This feature is _not_ worth dropping 2.6 support for.


Cool. =)

In that case, have the code throw `NotImplementedError` for Python 2.6?


That sounds reasonable.


+1


+1, if anyone would like to take a crack at the respective issue for urllib3, that would be appreciated. :)


@shazow see you over at shazow/urllib3#9 ...


@kennethreitz I've had a look around urllib3 and started working on getting `source_address` into the API. Making it work is easy, making it fail nicely is much harder. How would you envision exposing `source_address` in the the requests' API? 

I'm struggling with a good way to avoid making an API that invites user's to over specify the outbound sockets used by the connection pool such that they are slammed with _error 98_'s and we are slammed with all sorts of impossible to reproduce issues around socket allocation/release.


@fhsm, think about how you might sanely like to access the `source_address` attribute? I would think it could be an attribute on the `Response` object, but then we're currently under a feature freeze (see: #1168, #1165). I would hope this doesn't get bumped due to it though, since it was an accepted feature before the freeze started.


@fhsm if you specify a port of 0 then that's the magic code to let the OS pick a free port for you.

I have a branch with source_address support working, conversation will probably happen here: https://github.com/shazow/urllib3/issues/9#issuecomment-15871420 but I'll leave a comment here for people landing here from google.
OAuth package ignore path segments when signing request.

Not a Request issue, but just in case......

When signing a url  like http://www.sample.com/mylogs;version=1.1  the ";version=1.1" won't be taken in account, so the request will probably fail due to invalid signature. 

path segment are ignored on:

oauthlib/oauth1/rfc5849/signature.py:

def normalize_base_string_uri(...)
    return urlparse.urlunparse((scheme, netloc, path, u'',u'',u''))

This should fix it:
  return urlparse.urlunparse((scheme, netloc, path, params, u'',u''))


Could you please raise this issue against [oauthlib](https://github.com/idan/oauthlib)? As you pointed out, this issue is not in requests.

Thanks!
Unable to supress equals sign in query string for singleton keys

Hi Ken,

I really appreciate the Python Requests library that you have put together…  It really saves a lot of plumbing when using a REST API from Python.
However, I have run into an issue sending a singleton key using the library and have not been able to figure out how to suppress the = that is passed as part of the query string.  I have tried setting the value of the key to None and an empty string ‘’  but the equals sign is still sent to apache.
It looks to me that keys without values are legitimate according to http://en.wikipedia.org/wiki/Query_string#Web_forms 
Quote:
• Within each pair, the field name and value are separated by an equals sign. The equals sign may be omitted if the value is an empty string.

How hard would it be to suppress the = in the URL when the value for the key is None?  As an example, I added key3 to the dictionary in your documentation below.
http://docs.python-requests.org/en/latest/user/quickstart/#passing-parameters-in-urls

> > > payload = {'key1': 'value1', 'key2': 'value2', ‘key3’:None}
> > > r = requests.get("http://httpbin.org/get", params=payload)

You can see that the URL has been correctly encoded by printing the URL:

> > > print r.url
> > > u'http://httpbin.org/get?key2=value2&key3&key1=value1'

  --jim


This issue has been raised before (see the discussion after the closing of #917). To summarize that discussion, the [HTML5 working draft spec](http://www.w3.org/TR/2012/WD-html5-20120329/) (4.10.22.5, point 4.10) is clear that the `=` character must be present. Suppressing the `=` sign is therefore against the standard, and so we won't be making this change in the library. =)

You have a few options. You can construct the query string yourself and append it, e.g.

``` python
query_string = "?key2=value2&key3&key1=value1'
url = 'http://httpbin.org/get' + query_string
```

Or you can use the [pre-request Event Hook](http://docs.python-requests.org/en/latest/user/advanced/#event-hooks) to intercept the URL at the last minute and remove any equals signs you don't want. This is probably neater. =)

Thanks for your suggestion! If you're still having problems, let me know. =D


As I wrote in issue #917

> [It's misleading at best to have to embed query string into url in spite of the fact there's `params` param.](https://github.com/kennethreitz/requests/issues/917#issuecomment-10707261)

It's just bad api.
I'll be counting all issues raising this problem This is the second one after #917.