Deleted cookies should be included in response.cookies

``` py
s = requests.Session()
r = s.get('https://httpbin.org/cookies/set?k2=v2&k1=v1', allow_redirects=False)
r.headers['set-cookie']
# 'k2=v2; Path=/, k1=v1; Path=/'
r.cookies.keys()
# ['k1', 'k2']

r = s.get('https://httpbin.org/cookies/delete?k1', allow_redirects=False)
r.headers['set-cookie']
# 'k1=; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-Age=0; Path=/'
r.cookies.keys()
# []
```

This is pretty frustrating when one is trying to build a custom response object off of a `requests.Response`. 

Expected behavior is `r.cookies` should include a CookieJar when a cookie is deleted (empty value) in the response.


Sorry, it's not clear to me: _why_ should deleted cookies be included in `r.cookies`?


Well, why _shouldn't_ they be?

Say, you have an endpoint that logs out a user. A log-out usually clears out browser cookies by specifying an empty key-value `set-cookie` header (like in the example above). If I'm using `requests` as a middleman/reverse-proxy between the browser and the log-out endpoint, it's my duty to pass down everything the log-out endpoint returns. If the deleted cookie is not passed down, the user won't be actually logged out.

I am manually parsing the headers because `CaseInsensitiveDict` (type of `Response.headers`) does not support multiple values for the same key (which is a whole different problem). It is completely normal to have multiple `set-cookie` keys in the header, but `Response.headers` messes up in these kind of situations. A better approach is to use something like [`MultiDict`](https://github.com/mitsuhiko/werkzeug/blob/285e300f7f5806253000f13b36e87ef10eccfae7/werkzeug/datastructures.py#L326) to store response headers. Again, this is a different issue.


So, `response.cookies` provides an indication of the cookies that are validly set after the request has completed. When we update a cookie with an expiry date in the past, that means the cookie is now unset, and should not validly be in the `CookieJar`. This logic is actually enforced by the `CookieJar` class itself and is not something we normally control.

If you're using requests as part of a middleman/reverse proxy, you can achieve exactly the effect you want by passing the `Set-Cookie` header on, unmolested. As a reverse proxy, you actually have little-to-no reason to care about the cookies at all, they're strictly a _user-agent_ concern. The only reason a reverse-proxy would care about cookies is to cache-invalidate for responses that contain `Vary: Cookie` headers.

What we need to decide is whether there is a compelling use-case in providing access to cookies that were _unset_ in a response, beyond simply querying `Set-Cookie` for them.

As to your claim that `CaseInsensitiveDict` does not support multiple values for the same key, that's true of the class itself but untrue of the way it's used. Headers, before they get to requests, go via urllib3. urllib3 uses its own class for holding headers, the `HTTPHeaderDict`. That dictionary coalesces together multiple header values by comma-separating their values, which means that by the time the CaseInsensitiveDict gets hold of them any repeated values received from the server are coalesced together. This is totally valid _except_ for the `Set-Cookie` header, unfortunately, which is the specific problem you're encountering, and is a known limitation of this approach in requests. However, in your case you have no need to handle header parsing yourself: simply use `response.raw.headers`.


> This logic is actually enforced by the CookieJar class itself and is not something we normally control.

Didn't know this, thanks.

> If you're using requests as part of a middleman/reverse proxy, you can achieve exactly the effect you want by passing the Set-Cookie header on, unmolested.

This is exactly how I started off, but started getting weird errors because there is only one `set-cookie` header in the response. For example, I had the following problem:

```
...
>>> r.headers['set-cookie']
foo=123; Expires=Thu, 17-Nov-2016 22:34:13 GMT; Path=/, 
bar=456; Expires=Wed, 18-Nov-2015 22:44:13 GMT; HttpOnly; Path=/
```

The browser, however, gets confused and sets the expiration date for `foo` as _18-Nov-201**5** 22:44:13_ instead of _17-Nov-201**6** 22:34:13_. So in this case, both cookies had the same expiration date.

Well, if `HTTPHeaderDict` is handling `Set-Cookie` like the way it is, then the underlying issue might be with urrlib3 or the browser. What do you think?


Screenshots:

![](https://cloud.githubusercontent.com/assets/1221480/11257115/4d9a4250-8e15-11e5-9758-f61a0b5e51af.png)

![](https://cloud.githubusercontent.com/assets/1221480/11257133/5dcfb13c-8e15-11e5-8c56-aab020e2b593.png)


Why not something like:

``` py
headers = r.raw.headers
for key in headers.keys():
    for value in headers.getlist(key):
        # pass on (key, value) as a header-name: header-value pair
```


@Bekt The problem with the header dict is that `Set-Cookie` _cannot_ be simply joined by commas in the general case, because its values _contain_ commas. This is some truly terrible design, but we're stuck with it now. This is why you need to use @sigmavirus24's approach.


Ah I had not looked into the `HTTPHeaderDict` API, I just assumed it was similar to  `CaseInsensitiveDict`. Thanks for the suggestions guys! I probably would not have thought about looking into `raw` or `raw.headers` at all.

Here's what I ended up doing in case anybody is reading this:

``` py
r = requests.get|post|...

res = MyResponse(headers=r.headers.items())
res.headers.pop('set-cookie', None)
for c in r.raw.headers.getlist('set-cookie'):
    res.headers.add('set-cookie', c)
```