#19153 closed Cleanup/optimization (wontfix)
Deprecate GzipMiddleware
Reported by: | Aymeric Augustin | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Per PEP 3333:
applications and middleware must not apply any kind of Transfer-Encoding to their output, such as chunking or gzipping; as "hop-by-hop" operations, these encodings are the province of the actual web server/gateway.
Since WSGI has become by far the most common way to deploy Django — I don't even know any other way — Django should stop providing GzipMiddleware
.
This idea was approved by a BDFL on IRC:
20-00:10:33 jacobkm Oh and +1 on deprecating gzip middleware
Change History (8)
comment:1 by , 12 years ago
Has patch: | set |
---|
comment:2 by , 12 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Doesn't merge cleanly against master, since docs/releases/1.5.txt is probably intensively updated before release.
Patch works anyway.
comment:3 by , 12 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
If it doesn't merge then it isn't ready for checkin :)
I created a ticket instead of doing it myself because I think this deserves a serious discussion. Even though gzipping at the application level in wrong in theory, tons of people are doing it and it works in practice.
I'd like to see a discussion on django-developers before proceeding with this deprecation.
comment:4 by , 12 years ago
Oh, I'm sorry, the problem with merge was only in docs/releases/1.5.txt and it was trivial one.
comment:5 by , 12 years ago
Since filing this bug, I've come across a use case for GzipMiddleware.
It requires running Django with USE_ETAGS = True
behind nginx, with gzip compression enabled. In this situation, nginx will remove the etag (in modern versions) or keep it unchanged (in older versions). To get the correct behavior — ie. gzipping if the client supports it, and a different etag for the gzipped and non-gzipped version — you have to do the compression in Django.
comment:7 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:8 by , 7 years ago
This is an old ticket, but I thought it worth noting that recent versions of nginx will now downgrade the Django-generated etag to a "weak" etag rather than deleting it altogether when using nginx's gzip. At least for nginx users, this seems to remove the need for gzip middleware.
https://github.com/django/django/pull/455