Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -139,15 +139,16 @@ The <dfn>decompress and enqueue a chunk</dfn> algorithm, given a {{Decompression
1. If |buffer| is empty, return.
1. Let |arrays| be the result of splitting |buffer| into one or more non-empty pieces and converting them into {{Uint8Array}}s.
1. [=list/For each=] {{Uint8Array}} |array| of |arrays|, [=TransformStream/enqueue=] |array| in |ds|'s [=GenericTransformStream/transform=].
1. If the end of the compressed input has been reached, and |ds|'s [=DecompressionStream/context=] has not fully consumed |chunk|, then throw a {{TypeError}}.
</div>

<div algorithm>
The <dfn>decompress flush and enqueue</dfn> algorithm, which handles the end of data from the input {{ReadableStream}} object, given a {{DecompressionStream}} object |ds|, runs these steps:
1. Let |buffer| be the result of decompressing an empty input with |ds|'s <a for=DecompressionStream>format</a> and <a for=DecompressionStream>context</a>, with the finish flag.
1. If |buffer| is not empty:
1. Let |arrays| be the result of splitting |buffer| into one or more non-empty pieces and converting them into {{Uint8Array}}s.
1. [=list/For each=] {{Uint8Array}} |array| of |arrays|, [=TransformStream/enqueue=] |array| in |ds|'s [=GenericTransformStream/transform=].
1. If the end of the compressed input has not been reached, then throw a {{TypeError}}.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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..

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

1. If |buffer| is empty, return.
1. Let |arrays| be the result of splitting |buffer| into one or more non-empty pieces and converting them into {{Uint8Array}}s.
1. [=list/For each=] {{Uint8Array}} |array| of |arrays|, [=TransformStream/enqueue=] |array| in |ds|'s [=GenericTransformStream/transform=].
</div>


Expand Down