Explicitly call out what to do on the end of the compressed input

[saschanaz]

Fixes #76

• At least two implementers are interested (and none opposed):
  • Gecko
  • Blink (as this follows Blink behavior)
• Tests are written and can be reviewed and commented upon at:
  • https://phabricator.services.mozilla.com/D266433
• Implementation bugs are filed:
  • Chromium: N/A
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990921
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=299541
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[saschanaz]

This is the order of what Blink does, but does this matter right now? I couldn't craft a test input where this actually matters - flushing would actually enqueue any extra chunk, even though this theoretically can happen..

[ricea]

The implementation of inflate() used by Blink has this comment:

   In this implementation, the flush parameter of inflate() only affects the
   return code (per zlib.h).  inflate() always writes as much as possible to
   strm->next_out, given the space available and the provided input--the effect
   documented in zlib.h of Z_SYNC_FLUSH. 

I think this implies that in some other implementation it could make a difference, but it doesn't in Blink.

I think it anyway it can only apply to the "deflate-raw" format, as "deflate" and "gzip" both end with checksums.

RFC1951 doesn't seem to shed any light on the behaviour of decompressors.

My feeling is that it is good for the standard to be explicit about how to handle any remaining output, even if real implementations don't need this step.

[ricea]

lgtm, thanks!

[ricea]

The implementation of inflate() used by Blink has this comment:

   In this implementation, the flush parameter of inflate() only affects the
   return code (per zlib.h).  inflate() always writes as much as possible to
   strm->next_out, given the space available and the provided input--the effect
   documented in zlib.h of Z_SYNC_FLUSH. 

I think this implies that in some other implementation it could make a difference, but it doesn't in Blink.

I think it anyway it can only apply to the "deflate-raw" format, as "deflate" and "gzip" both end with checksums.

RFC1951 doesn't seem to shed any light on the behaviour of decompressors.

My feeling is that it is good for the standard to be explicit about how to handle any remaining output, even if real implementations don't need this step.

[saschanaz]

Test is pending automerge in web-platform-tests/wpt#55118. Feel free to merge this PR as I don't have the write permission.