When a response with status code 204 is received the package still tries to parser its bytes and get an exception

our rails server send status_code 204 for some logout requests (a delete with some cookies), and hence the message has no body
however in a code I catch the following exception:

/usr/local/lib/python2.7/dist-packages/requests/api.pyc in request(method, url, **kwargs)
     54     # cases, and look like a memory leak in others.
     55     with sessions.Session() as session:
---> 56         return session.request(method=method, url=url, **kwargs)
     57 
     58 

/usr/local/lib/python2.7/dist-packages/requests/sessions.pyc in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert, json)
    486         }
    487         send_kwargs.update(settings)
--> 488         resp = self.send(prep, **send_kwargs)
    489 
    490         return resp

/usr/local/lib/python2.7/dist-packages/requests/sessions.pyc in send(self, request, **kwargs)
    639 
    640         if not stream:
--> 641             r.content
    642 
    643         return r

/usr/local/lib/python2.7/dist-packages/requests/models.pyc in content(self)
    779                 self._content = None
    780             else:
--> 781                 self._content = bytes().join(self.iter_content(CONTENT_CHUNK_SIZE)) or bytes()
    782 
    783         self._content_consumed = True

/usr/local/lib/python2.7/dist-packages/requests/models.pyc in generate()
    704                         yield chunk
    705                 except ProtocolError as e:
--> 706                     raise ChunkedEncodingError(e)
    707                 except DecodeError as e:
    708                     raise ContentDecodingError(e)

The problem is here: https://github.com/kennethreitz/requests/blob/master/requests/models.py#L778
for some reason the status code checks itself agains 0, and raw requests checks agains None
while raw request does contain all the headers it has no body and thus an iterator fails to iterate on an empty chunk.


Hey @elasti-georgeg, thanks for opening this issue. I am able to reproduce the issue you've listed but only with a 204 response containing a "Transfer-Encoding: chunked" header.

[RFC 7230 § 3.3.1](https://tools.ietf.org/html/rfc7230#section-3.3.1) states:

>A server MUST NOT send a Transfer-Encoding header field in any
   response with a status code of 1xx (Informational) or 204 (No
   Content). 

This appears to be what is causing the ChunkedEncodingError which should be what we want in this scenario. Can you confirm you're receiving a Transfer-Encoding header? If that's the case, this is an issue that needs to be fixed with your Rails server.

The code below should allow you to perform the request without triggering the error. Just make sure you aren't calling `.content` on the response.
```python
s = requests.Session()
r = s.get(url, stream=True)
r.headers
```

@nateprewitt yes, they should fix that there, but we should also be able to tolerate this.

Hmm, so if a server says Transfer-Encoding: chunked but fails to use that encoding, can we reliably do anything other than raise an exception? The response only fails if it doesn't include `0\r\n` stating the body has ended, which I was under the impression is required. Requests doesn't explicitly prohibit a 204 with a chunked header, but does require the server to adhere to the encoding.

From Requests' end, we can do a forced `None` body for status codes that don't allow a body. That doesn't solve the core problem here though, which I don't know if we can do anything meaningful about.

Is httplib going to be able to tolerate this?

@Lukasa no, it won't because that's where the error is being raised from. httplib raises a IncompleteRead error of 0 bytes because the connection is terminated without sending anything.

Right, so it's very hard for us to tolerate this sensibly in the current codebase. 

We can probably close this out with the same reasoning in #3807, since we can't reasonably address this, and the exception is correct here.

Good catch @nateprewitt