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)
View Comments Responses to "Improving GZipMiddleware in Django"
You should file a bug on Django’s tracker. Trying to encode binary data is certainly not the correct behavior.
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?
@Jakub you are absolutely right that it would be much more efficient to use an existing solution rather than doing it in Python.
Nice. On nit: The class comment claims the opposite.
Nice. On nit: The class comment claims the opposite.
Well , the view of the passage is totally correct ,your details is really reasonable and you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum! http://spoon8.net/
Leave A Reply