I think the best way would be to create a new `CompressionMiddleware` that
uses brotli if it's both installed and the client accepts it, otherwise
gzip if the client accepts it, and deprecate `GZipMiddleware`.
There is a third party package, [https://github.com/illagrenan/django-
brotli django-brotli] but it seems a bit unmaintained. It is out of date -
it doesn't support compressing streaming responses as the brotli Python
bindings didn't support it, but it now does. It also doesn't have any
BREACH mitigation. For mostly this reason I'd like to bring it into core
as it's a bit security sensitive and good to have first class support for
this.
--
Ticket URL: <https://code.djangoproject.com/ticket/34916>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* resolution: => wontfix
Comment:
Please first start a discussion on the DevelopersMailingList, where you'll
reach a wider audience and see what other think, and
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features follow the guidelines with regards to
requesting features]. A new compression middleware doesn't need to be a
part of Django itself, and changing to `brotli` has some disadvantages:
it's slower than `gzip` and it's not so widely supported (but it's still
supported by most modern browsers).
> There is a third party package, django-brotli but it seems a bit
unmaintained. It is out of date - it doesn't support compressing streaming
responses as the brotli Python bindings didn't support it, but it now
does. It also doesn't have any BREACH mitigation.
My initial response, is that it's not Django job to maintain 3rd-party
packages. Especially, when they are not vital for the ecosystem and
doesn't seem very popular.
--
Ticket URL: <https://code.djangoproject.com/ticket/34916#comment:1>