Fix #77069: stream filter loses final block of data #6001
Conversation
|
I have just pushed a commit which fixes the so far failing ext/soap/tests/bug73037.phpt. The problem was that the zlib.deflate filter apparently assumed that when called with I wonder whether this assumption is a valid assumption for filters to make, because it is guaranteed the Could someone more proficient with the streams layer than I am please clarify? |
|
Maybe @sgolemon could have a look? |
Reading from a stream may return greater than zero, but nonetheless the stream's EOF flag may have been set. We have to cater to this condition by setting the close flag for filters.
If `inflate()` is called with flush mode `Z_FINISH`, but the output buffer is not large enough to inflate all available data, it fails with `Z_BUF_ERROR`. However, `Z_BUF_ERROR` is not fatal; in fact, the zlib manual states: "If deflate returns with Z_OK or Z_BUF_ERROR, this function must be called again with Z_FINISH and more output space (updated avail_out) but no more input data, until it returns with Z_STREAM_END or an error." Hence, we do so. This fixes the so far failing ext/soap/tests/bug73037.phpt.
|
I have rebased onto PHP-7.4, since it's a bit late for 7.3 fixes. I still wonder whether there is an implicit assumption that the |
|
@nikic, any thought on this. /cc @fisharebest |
Reading from a stream may return greater than zero, but nonetheless the
stream's EOF flag may have been set. We have to cater to this
condition by setting the close flag for filters.