Chunked responses lack data

Using urllib3 1.10.3 in python-etcd client.

We were hitting a really weird bug when occasonally we’d get

Traceback (most recent call last):
  File "etcd/lib_etcd.py", line 116, in _result_from_response
    res = json.loads(response.data.decode('utf-8'))
  File "~/soft/infra-virtenv/local/lib/python2.7/site-packages/urllib3/response.py", line 166, in data
    return self.read(cache_content=True)
  File "~/infra-virtenv/local/lib/python2.7/site-packages/urllib3/response.py", line 239, in read
    data = self._fp.read()
  File "/usr/lib/python2.7/httplib.py", line 549, in read
    return self._read_chunked(amt)
  File "/usr/lib/python2.7/httplib.py", line 622, in _read_chunked
    self._safe_read(2)      # toss the CRLF at the end of the chunk
  File "/usr/lib/python2.7/httplib.py", line 664, in _safe_read
    chunk = self.fp.read(min(amt, MAXAMOUNT))
AttributeError: 'NoneType' object has no attribute 'read'

on a chunked response from Etcd.

It seems to be related to the fact that HttpConectionPool#urlopen by default release_conn=True, which is dictated by preload_content

~/soft/infra-virtenv/lib/python2.7/site-packages/urllib3/connectionpool.py:510
        if release_conn is None:
            release_conn = response_kw.get('preload_content', True)

which means that if it is a chunked response, it will be closed immediately without the requesting library being able to read the content, since

~/soft/infra-virtenv/lib/python2.7/site-packages/urllib3/response.py:135
        # We certainly don't want to preload content when the response is chunked.
        if not self.chunked and preload_content and not self._body:
            self._body = self.read(decode_content=decode_content)

This is fine, as long as the connection doesn’t get reused, but under heavy load it causes things to break really badly.

[Lukasa]

RFC 2616 is not the specification for HTTP/1.1, RFC 7230 is. RFC 7230 says you cannot send both:

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

It’s good to know that removing it causes the same problem though. Let me see if I can adequately reproduce it locally.

[Lukasa]

The dummy server should handle multiple concurrent connections, being written in Tornado. As far as I know it doesn’t require any kind of synchronous execution.