Repository navigation
zlib: add raw content read methods to ZipEntry - #66801
Open
pipobscure wants to merge 1 commit into
Open
pipobscure wants to merge 1 commit into
pipobscure wants to merge 1 commit into
Conversation
zipEntry.rawContent was a getter that exposed the retained buffer of an in-memory entry and returned null for a file-backed or streaming one, so the still-compressed bytes of a member read through ZipFile could not be obtained at all. Replace it with rawContent(), rawContentSync() and rawContentIterator(), which mirror content(), contentSync() and contentIterator() but return the bytes as stored, without decompressing or verifying them. They work for every entry that has readable content, return caller-owned buffers from the buffered variants, and accept a maxSize bound on the compressed size. Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #66801 +/- ##
=======================================
Coverage 90.49% 90.49%
=======================================
Files 797 797
Lines 277686 277738 +52
Branches 53362 53370 +8
=======================================
+ Hits 251292 251348 +56
+ Misses 16796 16790 -6
- Partials 9598 9600 +2
🚀 New features to boost your workflow:
|
mcollina
added
the
request-ci
github-actions
Bot
removed
the
request-ci
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
zipEntry.rawContent was a getter that exposed the retained buffer of an in-memory entry and returned null for a file-backed or streaming one, so the still-compressed bytes of a member read through ZipFile could not be obtained at all.
Replace it with rawContent(), rawContentSync() and rawContentIterator(), which mirror content(), contentSync() and contentIterator() but return the bytes as stored, without decompressing or verifying them. They work for every entry that has readable content, return caller-owned buffers from the buffered variants, and accept a maxSize bound on the compressed size.
The motivation for this change is that I found a great use-case for this: web serving directly from an archive. If
Accept-Encoding: gziporAccept-Encoding: deflateis presented and the archive already has the part compressed that way, then it can serve that straight without any overhead.So I decided to change
rawContentfrom a getter to a function and have therawContentfamily of functions match what thecontentfunctions do. But since that changes the experimental API, it's probably a semver-minor.@mcollina can you advise if changing the API from getter to function is ok in an experimental thing?