Opened 7 years ago

Closed 4 years ago

#8034 closed New feature (wontfix)

Gzip Middleware And Images

Reported by: magneto Owned by: nobody
Component: HTTP handling Version: master
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 aaugustin)

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

Attachments (3)

gzip_middleware_no_images.diff (792 bytes) - added by magneto 7 years ago.
do not gzip image content-types
gzip_middleware_no_images.2.diff (796 bytes) - added by magneto 7 years ago.
Video and Images omit in Gzip (and use starts with)
gzip_middleware_no_images_startswith.diff (665 bytes) - added by magneto 7 years ago.
no vid and no images (bad diff file last time)

Download all attachments as: .zip

Change History (14)

Changed 7 years ago by magneto

do not gzip image content-types

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 7 years ago by magneto

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) ...

Changed 7 years ago by magneto

Video and Images omit in Gzip (and use starts with)

Changed 7 years ago by magneto

no vid and no images (bad diff file last time)

comment:3 Changed 7 years ago by adamfast

  • milestone set to post-1.0
  • Triage Stage changed from Unreviewed to Design decision needed

comment:4 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:5 Changed 6 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to HTTP handling

comment:6 Changed 6 years ago by robert.nitsch@…

*push*

comment:7 Changed 4 years ago by lukeplant

  • Severity set to Normal
  • Type set to New feature

comment:8 follow-up: Changed 4 years ago by aaugustin

  • Description modified (diff)
  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to 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.

comment:9 Changed 4 years ago by aaugustin

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:10 Changed 4 years ago by aaugustin

Oops, the triage guidelines say that only core devs are allowed to close tickets. Sorry.

comment:11 in reply to: ↑ 8 Changed 4 years ago by jacob

  • Resolution set to wontfix
  • Status changed from reopened to closed
  • UI/UX unset

aaugustin exactly right here. Large binary data shouldn't be served through Django, and if you must you should be turning off gzip middleware.

Note: See TracTickets for help on using tickets.
Back to Top