Incorrect Response Headers Leave Session in an Inconsistent State

I have a server that is misbehaving slightly when sending 304 responses. It sends a `304 Not Modified` response with an empty response body, but with `Content-Length: 4` and `Content-Type: application/json; charset=utf-8` in the header header. This seems to break the requests session:

```
session = requests.Session()
print 'Send req 1'
resp = session.request('get', url, headers={'if-none-match': etag, 'Authorization' : 'Bearer ' + token})
print resp.status_code, resp.headers

print 'Send req 2'
resp = session.request('get', url, headers={'if-none-match': etag, 'Authorization' : 'Bearer ' + token})
print resp.status_code, resp.headers
```

The call to second request simply hangs, and never returns.

## Expected Result

Either both requests should complete normally, or an exception should be raised.

## Actual Result

The first request leaves the session in some broken state, so any subsequent call will simply appear to be stuck.

## Reproduction Steps

See above.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  }, 
  "cryptography": {
    "version": ""
  }, 
  "idna": {
    "version": "2.6"
  }, 
  "implementation": {
    "name": "CPython", 
    "version": "2.7.10"
  }, 
  "platform": {
    "release": "16.7.0", 
    "system": "Darwin"
  }, 
  "pyOpenSSL": {
    "openssl_version": "", 
    "version": null
  }, 
  "requests": {
    "version": "2.18.4"
  }, 
  "system_ssl": {
    "version": "9081df"
  }, 
  "urllib3": {
    "version": "1.22"
  }, 
  "using_pyopenssl": false
}
```

If this is happening that server isn't misbehaving, Requests/urllib3 is. 304's with Content-Length that corresponds to the cached entity body are entirely allowed, so this should work just fine. I'll see if I can reproduce.

I think in this case the server might be genuinely misbehaving. Here's a wire-level trace of the response:

```
0000: 48 54 54 50 2F 31 2E 31   20 33 30 34 20 4E 6F 74  HTTP/1.1 304 Not
0010: 20 4D 6F 64 69 66 69 65   64 0D 0A 53 65 72 76 65   Modified..Serve
0020: 72 3A 20 6E 67 69 6E 78   0D 0A 44 61 74 65 3A 20  r: nginx..Date: 
0030: 53 75 6E 2C 20 32 37 20   41 75 67 20 32 30 31 37  Sun, 27 Aug 2017
0040: 20 30 36 3A 34 34 3A 34   32 20 47 4D 54 0D 0A 43   06:44:42 GMT..C
0050: 6F 6E 74 65 6E 74 2D 54   79 70 65 3A 20 61 70 70  ontent-Type: app
0060: 6C 69 63 61 74 69 6F 6E   2F 6A 73 6F 6E 3B 20 63  lication/json; c
0070: 68 61 72 73 65 74 3D 75   74 66 2D 38 0D 0A 43 6F  harset=utf-8..Co
0080: 6E 74 65 6E 74 2D 4C 65   6E 67 74 68 3A 20 34 0D  ntent-Length: 4.
0090: 0A 43 6F 6E 6E 65 63 74   69 6F 6E 3A 20 6B 65 65  .Connection: kee
00A0: 70 2D 61 6C 69 76 65 0D   0A 41 63 63 65 73 73 2D  p-alive..Access-
00B0: 43 6F 6E 74 72 6F 6C 2D   41 6C 6C 6F 77 2D 4F 72  Control-Allow-Or
00C0: 69 67 69 6E 3A 20 2A 0D   0A 43 61 63 68 65 2D 43  igin: *..Cache-C
00D0: 6F 6E 74 72 6F 6C 3A 20   6E 6F 2D 63 61 63 68 65  ontrol: no-cache
00E0: 0D 0A 53 74 72 69 63 74   2D 54 72 61 6E 73 70 6F  ..Strict-Transpo
00F0: 72 74 2D 53 65 63 75 72   69 74 79 3A 20 6D 61 78  rt-Security: max
0100: 2D 61 67 65 3D 33 31 35   35 36 39 32 36 3B 20 69  -age=31556926; i
0110: 6E 63 6C 75 64 65 53 75   62 44 6F 6D 61 69 6E 73  ncludeSubDomains
0120: 3B 20 70 72 65 6C 6F 61   64 0D 0A 0D 0A 6E 75 6C  ; preload....nul
0130: 6C                                                                                     l
```

Notice the payload string `null` at the end of the message. According to the HTTP spec, however, a 304 response "must not" contain a message body. And FWIW, I was able to reproduce this problem with a client written in Java too, so it's not specific to Python either.

It would be great if requests can raise an exception in this type of situations though.

*Ah*, yes, ok. So it's not that it's sending 304 with *no* body, it's that it's sending 304 *with* a body, which is against the spec.

We could raise exceptions in this case, certainly, but it's very hard to detect. For example, the presence of the content-length header is not an indication of this problem, as it's completely allowed to send a content-length that applies to the cached response. There is really no way to know except to try to parse the next response, which is apparently failing.

This is very difficult for us to handle except via timeouts and retries, which we already have support for, so my recommendation is to use the support we have for providing timeout objects to urllib3 to set timeouts on your requests and then retry ones that fail.