> > I would require some kind of configuration to define which response > content-type should be encoded by which algorithm.
I think there's room there to support custom tactics, for example content length may also be useful to determine which algorithms are applicable, or perhaps compression could be disabled for certain URL's. GZipMiddleware doesn't support this but if we're going to add flexibility we should make it easy to customize, at least by subclassing. On Sat, 15 Sep 2018 at 11:37, Johannes Hoppe <i...@johanneshoppe.com> wrote: > Hi Curtis, > > very good remarks. I would make sense to provide the best possible preset > for such a middleware. That could even be content-type sensitive. > I would however add any settings to overwrite the preset. I believe if > someone want to mingle with those things, one should inherit and override. > > But even with a preset, I would follow content negotiation tactics, where > the request can define preference over the content encoding. > https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3 > > Best > -Joe > > On Friday, September 14, 2018 at 12:53:34 PM UTC+2, Curtis Maloney wrote: >> >> On 09/14/2018 08:24 PM, Aymeric Augustin wrote: >> > Hello, >> > >> > I would like to be sure that Brotli is actually faster. In my >> > experience, while decompression is fast, compression can be extremely >> slow. >> >> https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html >> >> It's primarily tuned for fast decompression, making it especially good >> for offline compression (i.e. compression of static assets on deploy) >> >> At lower levels it can get as good compression as gzip, but much faster, >> or similar speed for better results. IIRC the general "wisdom" is that >> brotli at level 4 is typically faster than gzip, and gives better >> results. >> >> I like the general idea of an "extensible" or plugin driven >> Content-Encoding handler, though it would require at least some >> preferencing engine so you can influence which algorithm is chosen by >> (a) browser supported, (b) local preference, and (c) content type. >> >> -- >> Curtis >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/3673361a-dc59-4d27-8050-1ab2cae5d11c%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/3673361a-dc59-4d27-8050-1ab2cae5d11c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0UEYxm%3DK4FNVG-KKSbYRCf8sLwZYijdbhGjnriEhhUxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
