zlib Error -2 while decompressing in 1.2.3

When using requests 1.2.3, I get zlib errors using easywebdav and requests. If I install 1.1.0 instead, it works fine.

  File "./export-setup-pages.py", line 84, in <module>
    downloadFolder(wikiWebDav, os.path.join(outputFolder, localPath))
  File "./export-setup-pages.py", line 30, in downloadFolder
    download(webDav, resource,  localPath, path)
  File "./export-setup-pages.py", line 41, in download
    webDav.download(remoteFile, localFile)
  File "./python-env/local/lib/python2.7/site-packages/easywebdav/client.py", line 127, in download
    shutil.copyfileobj(response.raw, f)
  File "/usr/lib/python2.7/shutil.py", line 49, in copyfileobj
    buf = fsrc.read(length)
  File "/media/speedy/development/projects/Other/OrionIT/scripts/woki/python-env/local/lib/python2.7/site-packages/requests/packages/urllib3/response.py", line 191, in read
    buf = self._decoder.decompress(binary_type())
zlib.error: Error -2 while decompressing: inconsistent stream state

Is this a known issue? I can't find anything on the interwebs. For background, I'm trying to download from confluence through an nginx proxy (I think)


So at some point between V1.1.0 and v1.2.3, urllib3 updated its decompression routines to use `zlib`. This has seemed to introduce some problem with gzip, though it's very unclear what that problem is at this stage. I believe this issue to be the same as #1472.

There is currently a urllib3 issue tracking this (shazow/urllib3#206), so I recommend you pop over to that and see if you can help them out there. =)


I don't think its the same issue as shazow/urllib3#206.
The problem is rather, that the decoder is exhaustet by requests itself to populate `Response.content` and when trying to read from the raw urllib3 response you one hits the same decoder requests already has used, which now has no content left.

Minimal example (modeled after the provided stacktrace):

``` py
import requests
import shutil
import StringIO

s = StringIO.StringIO()
r = requests.get('http://httpbin.org/gzip')
shutil.copyfileobj(r.raw, s)
```


On the other hand: According to the comment `models.py` you are only allowed to access `Response.raw` if the request was made with `stream=True`. And indeed, it works then. I will check easywebdav and take a look how requests are made.


Yep. The problem is easywebdav not setting `stream=True`.
I don't know if this should be treated as a regression, as the comment doesn't allow the usage of `Response.raw` without this parameter.
Someone with authority should decide this.


Thanks so much for doing the detective work @t-8ch! The interface is very clear, you cannot use `Response.raw` unless `stream=True`, and that has been the case for a very long time. The `stream` parameter was introduced in 1.0.0 and the note you're referencing was also added in the same release.

With such a note in place, Requests was within its rights to do whatever it wants to the `raw` parameter when `stream` isn't set to `True`. I recommend opening a PR on easywebdav to fix this problem.

Thanks for raising this issue @skestle, and thanks so much for your investigation @t-8ch! :star2: :cake: :star2:


Found a way to reproduce this:

``` python
>>> r = requests.get('http://httpbin.org/gzip', stream=True)
>>> _ = r.raw.read(10000, decode_content=True); print len(_)
382
>>> _ = r.raw.read(10000, decode_content=True); print len(_)
0
>>> _ = r.raw.read(10000, decode_content=True); print len(_)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/bryanhelmig/.virtualenvs/zapier/lib/python2.7/site-packages/requests/packages/urllib3/response.py", line 224, in read
    "failed to decode it." % content_encoding, e)
DecodeError: ('Received response with content-encoding: gzip, but failed to decode it.', error('Error -2 while decompressing: inconsistent stream state',))
```

For anyone Googling this. Dunno if it is a bug? But if the server is not delivering gzip - you can read from the socket all day long with no stream errors.


@bryanhelmig your problem here is entirely unrelated to the bug originally reported. The original report is about consuming from requests' API first and then consuming from the raw attribute. This seems different to me even thought the message from the gzip library is the same


Oops, indeed it is. I've been Googling around a bit - forgive me for the random comment. If nothing else someone might be able springboard off from the same error message. Apologies!


## No worries. I think I might toy with your code though. I'm curious why that's happening 

Sent from my Android device with K-9 Mail. Please excuse my brevity.