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)

Presenting django-devserver, a better runserver. (February 9th, 2010)
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)

CC

Nice. On nit: The class comment claims the opposite.

Dave Smith

Nice. On nit: The class comment claims the opposite.

David

@Jakub you are absolutely right that it would be much more efficient to use an existing solution rather than doing it in Python.

Jakub

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?