On 10 août 2013, at 05:09, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> I also have a nagging feeling in the back of my head that there have been > questions raised about whether GZIPMiddleware should exist *at all* -- that > there's some niggling detail in the WSGI spec that says that GZip compression > should be applied at the web server level, not the WSGI level. Can anyone > confirm if I'm hallucinating on this point? I was under the same impression, but after double-checking the PEP, I don't think it forbids content encoding at the application level. (It does forbid transport encoding, for example chunking.) >From http://www.python.org/dev/peps/pep-0333/#other-http-features: > the application should use a suitable content encoding on its own, and must > not apply a transport encoding. Content encoding likely refers to the Content-Encoding HTTP header, which is used for delivering gzipped content. > And if I'm not, perhaps we should just be deprecating GZipMiddlware? At this point, there's a good practical reason for keeping it. 1) There are valid use cases for generating ETags at the application level, typically one may save CPU by doing something smarter than a hash of the final response. 2) Nginx is a common deployment platform and it strips ETags when gzipping content on the fly. As usual with nginx, documentation is sparse, but this thread explains the problem: http://mailman.nginx.org/pipermail/nginx/2013-June/039319.html As a consequence, if we want to support ETags, Gzip and nginx, we have to provide compression at the application level. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
