Opened 13 months ago
Closed 13 months ago
#34916 closed New feature (wontfix)
Add support for brotli compression
Reported by: | Tom Carrick | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Now that the BREACH attack is mitigated in the GZipMiddleware
I wonder if it's time to consider adding brotli support.
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, 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.
Please first start a discussion on the DevelopersMailingList, where you'll reach a wider audience and see what other think, and 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 thangzip
and it's not so widely supported (but it's still supported by most modern browsers).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.