Add support for brotli compression

[Tom Carrick]

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.

[Mariusz Felisiak]

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 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.