Nice work, this was something I was looking into as well but didn't understand well enough to properly fix. I was trying to use distance > self.window.readable() as the conditional but that was giving true incorrectly once the window was fully read (?; not sure if this is the correct terminology, still don't feel like I fully understand the window).

The window is a simple circular buffer holding the last N bytes that have been decompressed. It's how copies from backward references are implemented (thus if you want to support the maximum backward distance of 32768, make sure the window buffer is at least 32K). Since it's circular, after the first N bytes have been decompressed, byte N+1 will overwrite byte 0, N+2 will over write byte 1, etc. Obviously, we don't want to do this until those old bytes have actually been read out by the user of InflateStream, so the number of unread bytes in the window is tracked in window.el / window.readable(). As these unread bytes are copied out to the buffer passed to InflateStream.read, window.el is decreased and thus window.buf.len - window.el (which is what window.writable() returns), is increased, indicating that there is more free space to continue decompressing. So window.el can't be used for checking that distances are valid. For example, if we fill a 32K window with 32K decompressed bytes but the buffer passed to read is also 32K, then window.el, window.ri, and window.wi all just end up back at 0, and there's nothing to distinguish this state from the initial state before we decompressed anything. Hence we have to keep track of the total number of bytes decompressed to properly check distances.