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
fix Content-Type for gzip in StaticFileHandler #1468
Conversation
This looks good, but can you add a test for it? You can add some small files with |
OK, I'll create a new PR with both the test and the fixes. |
You don't have to close this PR; you can just push a new commit to the branch. It's usually better to re-use an existing PR to keep all the discussion about a change in one place. |
Oh, OK. Reopening and pushing new changes. |
Some of the test failures aren't your fault; rebase or merge to get fixes for the twisted/asyncio stuff. You also need to replace a set literal in the test for python 2.6 compatibility. |
The python mimetypes module used by StaticFileHandler will recognize compression (gzip, bz2, etc.) as the file encoding, and will give the mime type for the uncompressed file. This commit will fix this behavior, so a gzip file will end up as application/gzip. Additionally, unknown file types (or known file types compressed with anything other than gzip) are served as application/octet-stream.
OK, rebased and fixed. |
fix Content-Type for gzip in StaticFileHandler
Checked encoding for compressed files, and serves the correct content type. This is based on the pull request by @aebrahim here: tornadoweb/tornado#1468
Checked encoding for compressed files, and serves the correct content type. This is based on the pull request by @aebrahim here: tornadoweb/tornado#1468
Python mimetypes module only recognizes gzip as the encoding. This will
detect a gzip encoding from mimetypes and make sure the Content-Type
ends up as application/gzip
This replaces #1465.