Zero-length chunks: are they expected? #1733
-
The last chunk in the below is of length zero: with httpx.stream('GET', 'https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-4.4-essentials_build.zip') as r:
for chunk in r.iter_bytes():
print(len(chunk)) is this expected? It also looks like with httpx.stream('GET', 'https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-4.4-essentials_build.zip') as r:
for chunk in r.iter_raw():
print(len(chunk)) since in this case there is no content-encoding, I guess I expect that Having a bit of a nose around the code, suspecting it's from Line 1483 in 47d712c decoder.flush() returns an empty bytes instance, this is passed to chunker.decode , and since chunk_size is None , a list containing this empty bytes instance is returned Line 172 in 47d712c and then each element of this list is yielded to the calling code This is related to uktrade/stream-unzip#13, where the code in stream-unzip does not expect any zero length chunks. Potentially stream-unzip should be robust against this case... but wasn't sure if this was desirable in httpx, so mentioning it here in case it is an issue to be addressed. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Thanks @michalc - I've escalated this into #1739. Short version is that we're not currently making any assertions one way or the other about if any chunks might be zero-length, but it'd clearly be preferable from a UX perspective if it didn't ever do this. |
Beta Was this translation helpful? Give feedback.
Thanks @michalc - I've escalated this into #1739.
Short version is that we're not currently making any assertions one way or the other about if any chunks might be zero-length, but it'd clearly be preferable from a UX perspective if it didn't ever do this.