Should the spec allow enqueueing on-the-go instead of storing them until the input is exhausted?

[saschanaz]

https://wicg.github.io/compression/#decompress-and-enqueue-a-chunk

Per the spec it's a must to complete the conversion first and then do the enqueue, but would it be bad to enqueue as soon as each output buffer is filled?

Not that there's any important reason to do that, just curious. Maybe enqueuing all at once (as the spec says) makes sure more consistent behavior among implementations, as impls with smaller buffer might enqueue things before error while others with larger buffer might enqueue nothing.

[ricea]

This actually protects against a use-after-free attack where the buffer is transferred away in the middle of being decompressed. Calling enqueue can result in executing user JavaScript. Maybe there should be a note about that.

It also ensures consistent and robust behaviour if JavaScript attempts to modify the buffer in the middle of decompression.

[ricea]

Making a copy of the input data before converting it would also be safe, and would be preferable for an implementation that does thread offloading. I'd be interested in changing the wording to make either approach valid.

[annevk]

How is either implementation not valid today? Would it be observable? (Note https://infra.spec.whatwg.org/#algorithm-conformance in particular.)

[ricea]

Yes, I think @annevk is correct. The key point for conformance is that the output represents the results of decompressing the contents of buffer as it was when step 2 was run. Copying buffer and decompressing it in pieces later is a valid implementation.

There should probably be a comment in the spec about why it is important to capture buffer at a single moment in time. Volunteers welcome.

Okay to close this issue?

[annevk]

If you think there should be a comment, we should probably keep this issue to track that.