Raibek/requests-github-issues huggingface dataset:
Kerberos support

A simple way to authenticate using Kerberos is blatantly missing from urllib/urllib2

Having (optional) Kerberos support in Requests would be awesome... here is a code example that does pretty much everything is needed http://bretm.wordpress.com/2010/09/03/python-kerberos-urllib2/

Thank you!


I'm looking into adding this, thanks for the suggestion!


Someone was working on this, but I haven't heard from him in a while.

I'd love to see a `requests-kerberos` module that provides the auth handler.


Was there a published tree with a starting point for this? Else if it's free I may take a stab.


Release v0.13.4 includes this (just add auth=requests.auth.HTTPKerberosAuth() to the keyword args to requests.get()) so perhaps this can be closed now...


:cake:


Said code appears to have been ripped out in 377078b0f5cc5944756635f6e506d208b421b1e1


correct, there is now a requests-keroberos project which will contain this functionality

https://github.com/requests/requests-kerberos


Which doesn't work, and when fixed will continue to rot when you change an interface.

Which isn't packaged by anyone and will be that much more effort to get into e.g. debian or ubuntu.

Security should never be a secondary feature that you have to go to extra lengths to enable.


The interface will never change. It was removed because I cannot maintain it.


(I apologize if this is coming across a bit confrontational, but I was unreasonably annoyed by the functionality I was wanting and expecting being removed in a commit labelled "hooks and such")


refactors are brutal :)


I say this about interfaces from the perspective of having made the code work again; some of the details of how the response hook is called appears to have changed since it was written.

I appreciate that this sort of thing is hard to maintain, but that's a reason to say "hey can someone write me a test" not quietly delete it in the apparent hope that nobody notices.


this was not quietly removed, requests was basically fully rewritten and stripped down of everything unnccesary. 

http://kennethreitz.org/exposures/announcing-requests-v1-0-0


Oops, I completely failed to find that.  I apologize for my implication.

Still, authentication methods ought to be core functionality and tested along with everything else; anything more complex than Basic is going to end up having to fiddle around behind the scenes.


The authentication interface and mechanism is a first-class citizen. Basic and Digest is all that will be supported in core. 


"Security is hard, batteries not included"


Pull request for requests_kerberos sent.


@kcr: The biggest problem requests-kerberos has is a lack of tests. If you want to contribute a test suite (or even just a couple of tests), that will greatly improve our ability to keep it up to date. =)


@Lukasa I suspect we'll be able to repurpose at least the setup parts of the Zephyr test suite we're working on over the next couple of weekends, we'll definitely be in touch about that :)


@eichin, link for the curious?


Also, can we move this over to requests/requests-kerberos#1?
request.header objects don't support the standard keys() method of dicts

`UserDict.DictMixin` derivatives should support [keys()](http://docs.python.org/library/userdict.html#UserDict.DictMixin), not `__keys__()`.  I'm guessing it was probably a typo :)

I took a peak at the code when I found the bug, and wonder if it wouldn't just be easier to use the attached code instead?  Maybe I'm missing something, but the only problem I can see is if you suddenly decided to start supporting _much_ older versions of Python.

Thanks,

James
Authorization header missing?

I'm confused why an Authorization header isn't sent on the first request, and seems dependent on a 401 coming back to trigger another request with the Authorization header?

``` python

import requests

r = requests.post("http://localhost:8080/", auth=('test', 'test'))
```

```
esummers@roentgenium:~$ netcat -l localhost 8080
POST / HTTP/1.1
Accept-Encoding: identity
Content-Length: 0
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded
Connection: close
User-Agent: Python-urllib/2.6
```


That's how it's supposed to work. The client doesn't know in advance if and what kind of authentication the server requires. Could be basic, digest, kerberos, NTLM, etc.


In my case I do know, and the server is unfortunately responding with a 403, which means requests gives up. I guess this is really a bug on the server side though. Feel free to close this 'wont-fix' or whatever :-)
allow_redirects doesn't work

I haven't had the opportunity to research this yet, but I thought I'd go ahead and submit it because it might be a while until I can.

```
>>> import requests
>>> response = requests.get('http://graph.facebook.com/espen.hogbakk/picture', allow_redirects=False)
>>> response.url
'http://profile.ak.fbcdn.net/hprofile-ak-snc4/23219_653735294_3452_q.jpg'
```


On a related note, I think there's something really weird going on with `Request#redirect`.


When `allow_redirects` is set to `True`, the redirection of non-GET/HEAD requests is allowed. [RFC 2616 10.3](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) says that test redirects should only occur w/ permission of the user (therefore, the flag).

When `allow_redirects` is set to `False` (default), GET and HEAD requests are redirected as usual, and a 301 result of a POST, will not be redirected.


Maybe `allow_redirects` should be renamed to avoid confusion.


I see.

I'm not sure that it's necessary to rename `allow_redirects`. It might be sufficient that it just isn't available as an argument to `api.get` and `api.head` (see [pull request #45](https://github.com/kennethreitz/requests/pull/45)).
Fix allow_redirects

Hi,

I have problems with the "allow_redirects" to the Request object. It seems that if you specify "allow_redirects=False" it still follows redirects. I think I've found the source of the problem on line 169 in models.py:

```
while (
            ('location' in r.headers) and
            ((self.method in ('GET', 'HEAD')) or
            (r.status_code is 303) or
            (self.allow_redirects))
        ):
```

Shouldt the `or (self.allow_redirects)` be `and (self.allow_redirects)`?


When `allow_redirects` is set to `True`, the redirection of non-GET/HEAD requests is allowed. [RFC 2616 10.3](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) says that these redirects should only occur w/ permission of the user (therefore, the flag).

When `allow_redirects` is set to `False` (default), GET and HEAD requests are redirected as usual, and a 301 result of a POST, will not be redirected.


I'm considering renaming `allow_redirects` to avoid confusion.
Support relative redirects. Fixes #36

![Meme](http://i.imgur.com/kXzcW.jpg)


Haha! Thanks :)


![](https://d3nwyuy0nl342s.cloudfront.net/img/c583d6fdfaf7678a6617d01370bcbf914fef6897/687474703a2f2f692e696d6775722e636f6d2f626575426d2e6a7067)
Migrate settings to new module

I've completed the migration of the requests settings to the new `settings` module, but my attempt to facilitate for manipulating settings outside of the context manager (eg. `requests.settings.timeout = 5`) has been thwarted by the namespace collision of the context manager and the module.

I'm probably just being stupid. You'll figure it out.


I'll try to take a look at this tonight.


I moved `settings.py` to `config.py` and reimplemented the `Settings()` object as a singleton+context-manager+struct


Very good. I'm glad I wasn't just being stupid.
Exceptions

It's really tedious to catch timeouts in urllib2.

```
import requests
import urllib2
import sockets

try:
    requests.get('http://google.com', timeout=0.0001)
except urllib2.URLError, error:
    if isinstance(error.reason, socket.timeout):
        print "oh noes."
```

I've implemented a new exception, Timeout, to alleviate that.

```
import requests

try:
    requests.get('http://google.com', timeout=0.0001)
except requests.Timeout:
    print "oh noes."
```

PS: I took the liberty of moving the exceptions from models.py to exceptions.py and importing them in the request module so they may be referenced as `requests.Exception` instead of `requests.models.Exception`, but it's totally fine if you don't want to merge that.


I've thinking about this lately, actually. My thought was to either raise an exception (as you suggest) or return a `Response` object with that `URLError` attached at `Response.error`.

Raising an exception makes sense to me if a timeout is something that is explicitly added, as it is currently.


Also, Ideally, I'd like for the logic that has been added to `__init__.py` to be moved into `core.py`, but I haven't taken the time to investigate yet. 


Thanks for the contribution! This is awesome.

FYI, I moved a few things around (out of `__init__.py`).


> I've thinking about this lately, actually. My thought was to either raise an exception (as you suggest) or return a Response object with that URLError attached at Response.error.
> 
> Raising an exception makes sense to me if a timeout is something that is explicitly added, as it is currently.

I think that, too, would be an improvement to the way timeouts are currently "disguised" in an URLError.

> Also, Ideally, I'd like for the logic that has been added to **init**.py to be moved into core.py, but I haven't taken the time to investigate yet.

Yes. In fact, how do you feel about moving the settings and the settings context manager to new and aptly-named module `settings`?

**EDIT:** You beat me to it!


@jgorset already done :)

**EDIT:** You already know :P
GET request to PyPI does not work

Hi, `requests` it is fantastic!
But if I try to retrieve data from `http://pypi.python.org/simple/sphinx/` I get the following error:

```
ValueError: unknown url type: /simple/Sphinx
```

That is because PyPI redirects me to that url. You should really allow redirections.

rubik


Requests does have extensive redirection support. Looks like PyPI is attempting a relative redirect. I don't think that's a valid redirect, but I'll try to support it.


Yeah, that's not a valid form of redirection.

See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

I see no harm in trying to support it though.


Ok, thank you. I didn't know that.


Support for this was just added. It will be included in the next release.


Ok thank you very much!


:sparkles::cake::sparkles:
fix for post non-dict data

raised Attribute Error when post str data something like json because of not having 'items' attribute.
move encoding data to utf-8 inside hasattr(data, 'items')


Awesome, Thanks for the contribution! 

This is merged in now.


glad to be some help.
in addition, my screen name is megane murayama.
sorry for making you confuse about japanese language.


No worries, I'll fix the AUTHORS file. Thanks!
Encode both keys and values for incoming unicode data as UTF-8

Hi Kenneth,

I've pushed a commit that improves upon [b6f60](https://github.com/kennethreitz/requests/commit/b6f6048cff7189afee6a4fb89f9f0cdca0095b66) to encode both keys and values as UTF-8 byte strings, coincidentally fixing a bug that caused byte strings that were already encoded as UTF-8 from being encoded again and causing an UnicodeDecodeError.


Excellent, thank you!
Facilitation for non-ASCII-compatible unicode strings

requests is incompatible with unicode strings that contain non-ASCII characters because it relies on urllib to coerce dictionaries into their query string equivalents:

```
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    print requests.get('http://example.org', params={'foo': u'føø'})
  File "/Library/Python/2.6/site-packages/requests/core.py", line 467, in get
    return request('GET', url, params=params, headers=headers, cookies=cookies, auth=auth)
  File "/Library/Python/2.6/site-packages/requests/core.py", line 451, in request
    auth=kwargs.pop('auth', auth_manager.get_auth(url)))
  File "/Library/Python/2.6/site-packages/requests/core.py", line 76, in __init__
    self._enc_data = urllib.urlencode(data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1261, in urlencode
    v = quote_plus(str(v))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-2: ordinal not in range(128)
```

This shortcoming has been [discussed](http://mail.python.org/pipermail/python-dev/2006-July/067248.html) in the python-dev mailing list, wherein it is agreed that urllib should raise a TypeError if its arguments are not byte strings. This was never implemented, however, and while the exception it raises now is certainly an improvement to the one it produced back then, urllib continues to raise it only if an unicode string cannot be encoded with the system's default encoding (which, in turn, defaults to ASCII).

```
# This works, because all characters in the word "foo" exist in ASCII
requests.get('http://example.org', params={'foo': u'foo'})

# This doesn't work, because "ø" does not exist in ASCII
requests.get('http://example.org', params={'foo': u'føø'})

# This remedies the issue, but is arguably not the right place to be doing it
requests.get('http://example.org', params={'foo': u'føø'.encode('utf-8')})
```

It may be outside the scope of this library to facilitate for urllib so that it does not choke on ASCII-incompatible unicode strings, but I would at least consider to either transparently encode unicode strings as UTF-8 or raise a TypeError upon receiving unicode strings as request data or parameters.


First off, thanks for this extremely thorough Issue. I wish they were all was like this. :cake:

Putting workarounds in place for urllib's fallacies is a definite goal of this project. 

New Feature: **transparently convert unicode url strings to UTF 8-encoded byte strings**
Context manager for settings

I've implemented a `settings` context manager as described in [pull request #25](https://github.com/kennethreitz/requests/pull/25#issuecomment-1039541).

```
>>> import requests
>>> with requests.settings(timeout=0.5):
...     requests.get('http://example.org') # Times out after 0.5 seconds
...     requests.get('http://example.org', timeout=10) # Times out after 10 seconds
```

Settings may also be manipulated separately:

```
>>> import requests
>>> requests.timeout = 0.5
>>> requests.get('http://example.org') # Times out after 0.5 seconds
```


I'm not sure that I'm happy about this implementation, but I had a hard time facilitating for manipulating settings both at the module level and through the context manager using any other configuration. You're welcome to review and improve the code.


@jgorset thanks! I'll try to take a look at this and add some tests later today
Timeout

I've implemented an optional `timeout` argument to the request functions. It defaults to `None`, which is the default timeout of python's socket library.


I agree; if a `settings` scope was to be implemented, it should be a shortcut to manipulating configuration variables at the module level.

For example:

```
import requests
with requests.settings(timeout=10, debug=True):
    requests.get('http://example.org')
```

... would be equivalent to...

```
import requests

requests.timeout = 10
requests.debug = True

requests.get('http://example.org')

requests.timeout = None
requests.debug = False
```


:+1: for the context manager. That's beautiful. 

Would you mind opening this as an Issue?


> Would you mind opening this as an Issue?

How about a [pull request](https://github.com/kennethreitz/requests/pull/26)?
Tracking chained redirection

Sometimes when you make a GET request the client follows multiple redirections. It would be cool to keep track of the URL followed and the relative status code in variable like:

``` pycon
>>> import requests
>>>  r = requests.get('http://example.org/first_redir.php')
>>> r.chained_dir
[('/first_redir.php', 302), ('/second_redir.php', 301)]
```


I'm +1 on this, though I suggest the entire response object is made available so one can inspect their headers retrospectively.

```
>> response = requests.get('http://example.org/redirect.html')
>> response.redirects
>> [<Response [301]>, <Response [301]>, <Response [301]>]
```


I agree with you jgorset. Is better to have the entire response object 


This is a good idea. I think a good place for would be `Response.history` as a property.

``` pycon
>>> r = requests.get('http://301x3')
>>> r.history
[<Response [301]>, <Response [301]>, <Response [301]>]
```

These response objects wouldn't contain any history themselves.

At the moment, all of the redirection is coming strait from urllib2 transparently. We'd have to write a custom HTTPRedirectHandler.

Reference: http://diveintopython.org/http_web_services/redirects.html


Yes, `Response.history` would be perfect.


+1 on this. I wrote a gnarly RedirectHandler for a work project that did something similar. It's not horrible, but not much fun either.


v0.4.0 was just released, which implements this. Enjoy :)


Nice work, @kennethreitz!


Thanks @kennethreitz!
Automatically Handle Server-side Compression

Reproducible example: 

```
import zlib
import requests

r = requests.get('http://api.stackoverflow.com/1.1/users/495995/top-answer-tags')

zlib.decompress(r.content, 16+zlib.MAX_WBITS)
```

This should already be decompressed because of the response header:

```
>>> r.headers['content-encoding']
'gip'
```
gzip decompression

Reproducible example: https://gist.github.com/913423


I don't have time right now to fork requests and implement this, but here is how httplib2 handles decompression:

http://www.google.com/codesearch/p?hl=en#7p4WlYhzLQw/trunk/httplib2/__init__.py&q=zlib%20package:http://httplib2%5C.googlecode%5C.com&l=347


Gzip'd data is supported and seamlessly decompressed by the underlying urllib2 library. 

Its possible the server isn't sending the gzipped data over:

```
r.headers['Accept-encoding'] = 'gzip'
```


Thanks, you are correct.


Actually, `content-encoding` is set to `gzip` and `accept-encoding` is unset. Afaik, the two headers have independent meanings, so urllib2 _should_ decompress the response.

References:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3


Ah, hmm...

Well if I can make it function better than urllib2 I'm all for it.


Tonight I'll file a bug in urllib2. Let me see if I can fix this...

Edit: Sorry, I keep closing this by accident. I'm not used to the way GitHub orders the buttons.


Moving to #19


Update: v0.3.2 was just released which includes automatic gzip encoded content decompression.
Fixing User-agent header problem introduced with Python 2.7.1

urllib2 changed the way OpenerDirector objects combine headers.  This resulted in a User-agent header never making it through the request.  Python's default `Python-urllib/2.7.1` would always be used.  In Python 2.7, this wasn't an issue.

This change is a bit hacky, but since the behavior changed with a standard module I'm not sure what the alternative is.  Perhaps subclassing the OpenerDirector?


Hmm, thanks for this. I did most of the development in python 2.7.1, and what I found is that i could only override user-agent if i fed it in lowercase ('user-agent' instead of 'User-Agent'). 

Would this be related?


Yeah, same exact chunk of code in urllib2 that handles this.  In the OpenerDirectory `addheaders` there is a capitalized version 'User-agent'.  If you give it exactly that, it won't let you set it period.  The chunk of code in urllib2 doesn't check case either, which I don't know if it should; I guess I'd need to read the HTTP spec.

Anyway, you give it 'user-agent' and it will set, but you'll also have a duplicated 'User-agent' that came with OpenerDirector.  Then I'm assuming it's up to the deterministic ordering of a normal dict which one it sends first.  Me I was using 'User-Agent' and it wasn't making it through.

I tested this one (manually, tox is misbehaving) with 2.5, 2.6, 2.7, 2.7.1, and pypy.


Excellent. Thanks for the patch! (and doing all the dirty work for me)   :) 

Merged.


w00t! http://ci.kennethreitz.com/job/requests-tests/61/


Good deal :D

On Mar 30, 2011, at 12:39 AM, kennethreitz wrote:

> w00t! http://ci.kennethreitz.com/job/requests-tests/61/
> 
> ## 
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/pull/17#issuecomment-934828
Issue #13: Poster headers preservation

These changes alter the way headers are handled in the `Request.send()` (line 181) method. `req.headers` will now be updated by, instead of assigned to, the `self.headers` value. This will preserve the headers generated by poster's multipart encoding.

I added a new test case `test_POSTBIN_GET_POST_FILES_WITH_HEADERS`. All tests pass.

Please let me know if you have any questions.


Oops! I didn't realize that a pull request would open an issue. This is now a duplicate of Issue #13 (hence the title).


Thank you very much! This was definitely needed.
Headers kwarg overrides Poster headers

If a caller uses both the `files` and `headers` kwargs in requests.request, the dictionary provided in `headers` will override the multipart encoding headers generated by Poster. See line 180 in core.py. Also, I am using v0.3.0

The request will fail with the following error:

```
ValueError: No Content-Length specified for iterable body
```

Example:

```
import requests

files={ "hello.txt.", "/path/to/file/hello.txt." }

# this works
requests.post('http://path/to/server', files=files)

# this does not work
requests.post('http://path/to/server', headers={ 'Accept' : 'application/json' }, files=files }
```


Better POSTER header compatibility (Closed by 9fdee250de7e1aa0c92db5fb435cf1f2f8efe7e7)
Cookies without cookiejar

I'd like to be able to just pass in a dict containing cookies for a request.


I considered this originally, but TBH haven't used cookiejars enough to know what the most common/simplest method is.

Without investigating, my thought it it would be simple to roll out support for both at the same time. 

Can you give me an example of how you'd pass in cookies by themselves and how that'd be useful? It would be much appreciated. 


I think @mcilrain might have been proposing something along the lines of...

```
requests.get('http://google.com', cookies={'cookie': 'value'})
```

I'll venture a guess that he was not aware that requests saves cookies it receives and attaches them to subsequent requests, though, which (besides being really awesome) complicates things because cookies set in this way would lack traits like expiry and domain.

It's entirely possible to create cookies programatically as it is, however it's... uh... a bit tedius:

```
from cookielib import CookieJar, Cookie

cookie = Cookie(
    version=0,
    name='Name',
    value='1',
    port=None,
    port_specified=False,
    domain='www.example.com',
    domain_specified=False,
    domain_initial_dot=False,
    path='/',
    path_specified=True,
    secure=False,
    expires=None,
    discard=True,
    comment=None,
    comment_url=None,
    rest={'HttpOnly': None},
    rfc2109=False
)

cookie_jar = CookieJar()
cookie_jar.set_cookie(cookie)

requests.get('http://google.com', cookies=cookie_jar)
```

I didn't specify 17 arguments to `Cookie` for fun, by the way; they're all required. It's pretty clear (and [documented](http://docs.python.org/library/cookielib.html#cookielib.Cookie), too) that developers are not expected to construct their own cookies.

I can see how being able to do that might be really useful, though.


`Cookie.SimpleCookie()` makes this easier.

``` python
import Cookie, cookielib, requests
# create cookiejar
cj = cookielib.CookieJar()
# create cookie
ck = Cookie.SimpleCookie()
ck.name = 'value'
ck.expires = 0
ck.path = '/'
ck.domain = 'www.example.com'
# add cookie to cookiejar
cj.set_cookie(ck)
# use cookiejar to make request
response = requests.get('http://www.example.com/home.php', cookies=cj)
```

( From http://stackoverflow.com/questions/6285378/how-can-i-use-a-cookie-to-enter-and-download-a-web-page-in-python/6285548#6285548 )


So why not to make support both for this (dict-like)

``` python
requests.get('http://google.com', cookies={'cookie': 'value'})
```

and CookieJar way?

It's really useful when you need to pass cookies directly, for example PHPSESSID cookie. Yes, you can do a few more requests to login into a website and automatically set cookies, but this is too much work for that.
Webapp for Testing 

### Thoughts;

Develop Flask application with routes to different testing mechanisms. 
- http://localhost:8080/post
- http://localhost:8080/post/cookie
- http://localhost:8080/post
- http://localhost:8080/head
- http://localhost:8080/del


I wrote a [simple test server](https://github.com/mrtazz/http-test-server) for testing my [C++ restclient](https://github.com/mrtazz/restclient-cpp). It is very simple, but may be useful for this (though it definitely needs some adaptions). It's also up on [heroku](http://http-test-server.heroku.com/).


mrtazz: Awesome! I may have to utilize that :)
Updates and Cleanup

I modified AuthObject to support a realm and all AuthHandlers supported by urllib2 as well as any handler class passed in by the user

Cleaned up the send method to get rid of all the duplicated code

cleaned up the helper methods since they were all doing the exact same thing just passing a diff method

removed the old auto_auth code and switched to using a proper auth_manager

added the **all** object to make 'from core import *' not expose all the stuff from urllib2


I think leaving the async stuff in the separate module is better, would be even better I think if it did not monkey patch but was importing urllib2 from eventlet or greenlet. The reason I think this is because Guido has said before that all async io should be perpended with 'async_' but since the current design does allow them to coexist I figure breaking them into separate modules is the best bet.


Thanks! I'll try to get some of these changes integrated this evening. 

FYI, these break tests in Py2.5 and PyPy.


http://ci.kennethreitz.com/job/requests-tests/37/


thanks, forgot the b'' was not backported to py2.5


No prob. Thanks for the contribution! I'm not sure I'll include all of the change, but I'll set some time later today to review (see comments above).


I'd like to thank you for this contribution. Upon further inspection and reflection, I see that you've really extended the capabilities of this module, and will be including all of your changes. 

These will be rolled out into the v0.3.0 Release tonight.
a "40x" error my have content

sometimes, a "40x" header does not mean you don't have content in your response. In fact, that's the 2nd time I'm working on a HTTP client that has to handle content, even if the HTTP return code is different than "200". An example : a webservice that throws a "403" error (forbidden) but outputs some content - in an XML structure, for example, a reason for the error : incorrect password, unauthorized operation, etc. This result is meaningful, and it helps to debug code.

Usually, I have to create a workaround using urllib rather than urllib2 to catch the response body, even if a "40x" error is thrown.

I thought "requests" would handle this, but I've tried to request my small test webservice, and here's the result :

```
>>> resp = requests.post('http://my-server/webservices/stuff', {'user': 'yada', 'pass': yada'})
>>> print resp
>>> <Response [403]> # this is correct, because user/pass is wrong
>>> print resp.content
None
```

But in my _actual_ response body, I've got XML (and I've checked).


You are correct. Thanks for the pointing out the discrepancy. 


Fixed! This will be merged into the next release. Hopefully this evening.

https://github.com/kennethreitz/requests/commit/10280c697dcfd3d334f1c9c381a11c324bb550bc


v0.2.2 was just released, which fixes this bug. Thanks!
Cookie support?

An feature request (not found in documentation).

Does this support cookies?

Usecase: I can integrate this module inside an existings framework. This framework generate for me the authentication/session cookie, so to perform request using requests there I need to add the same auth cookie already generated.


It does not yet, but I am planning on adding that in to the next release.

It's just a matter of keeping the api as elegant as possible. What would you find appropriate? Just having a cookies list you can pass in (and build the cookies it yourself externally)?


Looking at the minimalistic approach of this library (that I think is what users will like ofit) I think that adding only a feature for adding a list of cookie is enough!


My thoughts exactly.

Plan is to have an optional cookiejar paramater to the requests. You can then add your cookielib.CookieJar object there, and that will be passed along with the request. 


v0.2.2 was just released, which adds support for CookieJars. Thanks!

```
jar = cookielib.CookieJar()
#stuff w/ jar

requests.get('url', cookies=jar)
```