Opened 12 years ago

Closed 11 years ago

Last modified 7 years ago

#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:2 by Tomáš Ehrlich, 12 years ago

Triage Stage: AcceptedReady 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 Aymeric Augustin, 12 years ago

Triage Stage: Ready for checkinAccepted

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 Tomáš Ehrlich, 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 Aymeric Augustin, 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.

Related: #19705 and #16035.

comment:6 by Tim Graham, 11 years ago

Should we mark this as "won't fix" then?

comment:7 by Tim Graham, 11 years ago

Resolution: wontfix
Status: newclosed

comment:8 by alubbock, 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.

Note: See TracTickets for help on using tickets.
Back to Top