#8034 closed New feature (wontfix)
Gzip Middleware And Images — at Version 8
| Reported by: | magneto | Owned by: | nobody |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | gzip middleware |
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
In the random cases where Images (Gifs, JPEGS, PNG, etc) are passed through the Gzip middleware (usually through the static sender), sometimes they get 'truncated' (i think it may be a partial browser bug too)
but there is no reason to Gzip image content-types and waste the time/ram/etc in doing them
Change History (11)
by , 16 years ago
| Attachment: | gzip_middleware_no_images.diff added |
|---|
comment:1 by , 16 years ago
I'm not completely sure about this, since there are a number of valid image types that can benefit from zipping, but it's probably worth doing, since most of those image formats were last popular in 1989.
More concretely, however, reaching for the regular expression module as a way to emulate the startswith() method is poor form. The string method is both faster and more explicit.
comment:2 by , 16 years ago
true indeed about the startswith ... but while i'm at it i'll include video too .. ( i had some more complicated regex initially, to filter out those images that could be compressed, but the resources it takes to zip a 100 Mb Tiff or 2 Gb Mpeg2 in WSGI server mode was just silly) ...
by , 16 years ago
| Attachment: | gzip_middleware_no_images.2.diff added |
|---|
Video and Images omit in Gzip (and use starts with)
by , 16 years ago
| Attachment: | gzip_middleware_no_images_startswith.diff added |
|---|
no vid and no images (bad diff file last time)
comment:3 by , 16 years ago
| milestone: | → post-1.0 |
|---|---|
| Triage Stage: | Unreviewed → Design decision needed |
comment:5 by , 16 years ago
| Component: | Uncategorized → HTTP handling |
|---|
comment:7 by , 14 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:8 by , 13 years ago
| Description: | modified (diff) |
|---|---|
| Easy pickings: | unset |
| Resolution: | → wontfix |
| Status: | new → closed |
MIME types are defined here : http://www.iana.org/assignments/media-types/index.html and valid types include application/*, audio/*, example/*, image/*, message/*, model/*, multipart/*, text/*, video/*.
If we hardcode that image/* and video/* must not be compressed, we should also add audio/* to the list. But this technique is crude: for instance, application/xml should be compressed; application/mp4 and application/octet-stream shouldn't. We're going to have debates about the proper whitelist / blacklist. And adding yet another setting is not the solution. In short, the patch doesn't smell good.
Let's look at the problem differently. It's an Horribly Bad Idea to serve "a 100 Mb Tiff or 2 Gb Mpeg2" through Django. Actually, serving anything that is not programmatically generated by Django through Django is grossly inefficient.
If someone is at that level of non-optimization, clearly, not compressing the HTML is not going to make a difference. Just disable GzipMiddleware and be done with it.
Given all this, plus the fact that the ticket has been rotting for two years, I will close it.
do not gzip image content-types