Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downloading gzipped files in browsers #158

Open
achingbrain opened this issue Feb 8, 2024 · 4 comments
Open

Downloading gzipped files in browsers #158

achingbrain opened this issue Feb 8, 2024 · 4 comments

Comments

@achingbrain
Copy link

If you try to download (for example) a .tar.gz via sirv in a browser, because the file name ends in .gz the toHeaders function sets Content-Encoding to "gzip".

This makes browsers ungzip the file before making the bytes available to the user.

If the intention was to download a .tar.gz file things break because they actually get back the equivalent of a .tar file.

achingbrain added a commit to hugomrdias/playwright-test that referenced this issue Feb 8, 2024
When loading a file that ends in `.gz`, `sirv` will set the
`Content-Encoding` header to `gzip` which means browsers will
unzip the content before handing it back to `fetch` or `XMLHttpRequest`.

This PR adds a workaround to the asset server that sets the header
to a garbage value if a file ending in `.gz` has been requested.

It's necessary to use a garbage value because `sirv` will only set
the header if it's not been set already, so we can't simply delete it.

Refs: lukeed/sirv#158
Refs: ipfs/aegir#1462
hugomrdias pushed a commit to hugomrdias/playwright-test that referenced this issue Feb 8, 2024
When loading a file that ends in `.gz`, `sirv` will set the
`Content-Encoding` header to `gzip` which means browsers will
unzip the content before handing it back to `fetch` or `XMLHttpRequest`.

This PR adds a workaround to the asset server that sets the header
to a garbage value if a file ending in `.gz` has been requested.

It's necessary to use a garbage value because `sirv` will only set
the header if it's not been set already, so we can't simply delete it.

Refs: lukeed/sirv#158
Refs: ipfs/aegir#1462
@achingbrain
Copy link
Author

achingbrain commented Feb 9, 2024

@lukeed would you accept a PR that added a detectFileCompression: boolean option (or similar, default: true) that if false would not set the Content-Encoding header?

@lukeed
Copy link
Owner

lukeed commented Feb 9, 2024

Hi there, thanks for the report

Agree that this should be fixed, however don't think adding a new config option is the solution here. I'll have a window today where I can put together what I have in mind

@lukeed
Copy link
Owner

lukeed commented Feb 10, 2024

@achingbrain Can you do me a favor & see if the following change works for you?

// circa L112
-- if (enc) headers['Content-Encoding'] = enc;
++ if (enc && ctype) headers['Content-Encoding'] = enc;

@achingbrain
Copy link
Author

achingbrain commented Feb 12, 2024

Thanks for taking a look.

That works, but only because mrmime doesn't currently map .tar to "application/x-tar", if it ever does that in the future it'll break again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants