Improving GZipMiddleware in Django

David Cramer's Blog

Apr

Improving GZipMiddleware in Django

Filed in Code, Django |

One issue we had come up over at iBegin lately, is the fact that GZipMiddleware tries to encode ALL responses (with a few minor exceptions). In our cases, we sometimes stream actual binary files over the response. Doing this with the standard middleware causes a unicode error as it’s trying to encode all of the information before gzipping it.

So to fix this, we simply created a slightly improved middleware to handle the content types a bit better:

from django.middleware.gzip import GZipMiddleware
 
class ImprovedGZipMiddleware(GZipMiddleware):
    """Will GZip the content if it's not text/*, xml, or a javascript content type."""
    def process_response(self, request, response):
        ctype = response.get('Content-Type', '').lower()
        if not ctype.startswith('text/')\
            or 'javascript' in ctype\
            or 'xml' in ctype:
            return response
        return super(ImprovedGZipMiddleware, self).process_response(request, response)

Debugging Django Errors (January 6th, 2010)
Big Companies Make Me Laugh (December 24th, 2009)
Jinja2 and django-registration (September 30th, 2009)
Using Jinja2 with Django (via Coffin) (September 14th, 2009)
Dynamic Keyword Arguments in Django URLs (July 15th, 2009)

5 Responses to "Improving GZipMiddleware in Django"

Subscribe to this topic with RSS or get the Trackback URL

Johann (Apr 17th):

You should file a bug on Django’s tracker. Trying to encode binary data is certainly not the correct behavior.

Jakub (Apr 17th):

I didn’t know that one actually uses this middleware in production. Shouldn’t the gzipping be done by the webserver (apache/lighttpd/ngix)?

We usually set up a ngix to serve the static files and as reverse proxy to put proper etags/expires headers and gzip responses from django runned on apache+mod_wsgi. I guess it’s faster than having all that work done by Django, isn’t it?