Avoid setting Content-Encoding header for static view responses. #2810
Conversation
This was causing clients to decode the content of gzipped files when downloading them. We discussed this on IRC and @mmerickel pointed out that it may be a goal in some cases to serve gzipped precompiled assets (i.e. CSS/Javascript) with this header. But that's a new feature that would require thought about how to specify which files to serve that way. And it can already be implemented for a project using a tween. This just aims to fix the existing use case of serving files for download.
| to an encoding guessed using Python's ``mimetypes`` module. | ||
| This was causing clients to decode the content of gzipped files | ||
| when downloading them. | ||
|
|
There was a problem hiding this comment.
Can add a link to the PR here similar to other changes please.
|
What's the protocol now? Shall I merge this myself? And backport to maintenance branches? |
|
This is technically bw-incompat and so I don't think we should backport it. I usually let things sit for a couple days just incase someone else feels like reviewing and then I'll merge it. |
|
Can we never backport bugfixes then? Or is there something bw-incompatible you're seeing apart from the bugfix itself? |
|
My hesitation was that it's a "bug" that's been there for a very long time. At what point does a bug become a feature? Thus it made sense to me to wait until a new major release to fix it (pyramid 1.8 is coming soon) where people may be more expecting of weird / breaking changes. However, I agree with you it's a bug so if you feel strongly enough about it then go ahead and push backported PRs to 1.7 and 1.6 branches. |
|
I don't feel strongly enough about it. :) |
|
I would argue that this introduces a backwards incompatible change that is being labeled as fixing a "bug". |
|
@bertjwregeer sorry I'm not quite sure what you're trying to say. |
|
CHANGES.txt says "Fix ..." as if it was fixing a bug. I'd argue that this should be "Change ...". I would also argue that this should be listed as a backwards incompatibility, as a new feature, even if it were intended to be originally as it is now. |
|
I see. I will update the changelog. |
This was causing clients to decode the content of gzipped files when downloading them.
We discussed this on IRC and @mmerickel pointed out that it may be a goal in some cases to serve gzipped precompiled assets (i.e. CSS/Javascript) with this header. But that's a new feature that would require thought about how to specify which files to serve that way. And it can already be
implemented for a project using a tween. This just aims to fix the existing use case of serving files for download.