On 10 août 2013, at 05:09, Russell Keith-Magee <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
