[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#972632: apache2: please provide compression snippet to support brotli (not only deflate)



Package: apache2
Version: 2.4.46-1
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

apache2 ships with on-the-fly compression modules deflate and brotli,
but whereas deflate is both enabled and configured by default,
brotli is disabled and lack any default configuration.
Moreover, the default deflate configuration conflicts with brotli.

Brotli compresses to roughly %10 smaller output but is less supported -
currently 94% coverage according to https://caniuse.com/?search=brotli

I think it makes sense to continue shipping with deflate enabled and
configured same as now, but change _how_ that is done and extend to support
both a) shifting to brotli and b) using deflate and brotli concurrently.


Please...:

 1) Move mods-available/deflate.conf to conf-available/compression.conf
    (i.e. ship the old file only with a comment about its new location)
 2) Have dpkg enable conf compression, on fresh installs
 3) Have dpkg enable conf compression, on migration from 2.4.46-1 or older

Above should be functionally same setup as now, but with these new
features:

  * enable/disable deflate completely using "a2{en,dis}mod deflate"
  * enable selectively per-vhost by using "a2disconf compression"
    and adding "include conf-available/compression.conf" within a vhost

Since mods-available/deflate.conf is a conffile, Users who customized
their deflate config will get notified that they might need to adapt.


Then also, please...:

  4) Have conf compression snippet separate detection from use
     i.e. first set ENABLE_COMPRESSION=DEFLATE, unless already defined
     then use ${ENABLE_COMPRESSION}
  5) extend conf compression snippet to first detect mod_brotli
     i.e. enable that _instead_ of deflate if detected or predefined

I.e. the final conf-available/compression.conf file would contain this:

<IfModule mod_brotli.c>
  <IfDefine !TRANSFER_COMPRESSION>
    Define TRANSFER_COMPRESSION BROTLI_COMPRESS
  </IfDefine>
</IfModule>
<IfModule mod_deflate.c>
  <IfDefine !TRANSFER_COMPRESSION>
    Define TRANSFER_COMPRESSION DEFLATE
  </IfDefine>
</IfModule>
<IfDefine TRANSFER_COMPRESSION>
  <IfModule mod_filter.c>
    AddOutputFilterByType ${TRANSFER_COMPRESSION} text/html text/plain text/xml text/css text/javascript
    AddOutputFilterByType ${TRANSFER_COMPRESSION} application/x-javascript application/javascript application/ecmascript
    AddOutputFilterByType ${TRANSFER_COMPRESSION} application/rss+xml
    AddOutputFilterByType ${TRANSFER_COMPRESSION} application/xml
  </IfModule>
</IfDefine>


All of the above together should support all combinations of
none/custom/brotli/deflate for generally/per-vhost scenarios,
and I believe migrations for existing systems is reasonably graceful
but I will leave the final judgement of that in your hands. :-)


 - Jonas


P.S.

This bugreport only covers compression applied to _transfer_ encoding.
Covering _content_ encoding a.k.a. pre-compressed files is more tricky
because it ties more intimately into the kind of data served.
Notably it ties into setup of mime module which currently has _file_
extension .br linked with brazilian portuguese lanugage which would need
to get fixed first, e.g. to more properly (only!) use extension .pt-br.

It might make sense to extend conf compression snippet with the content
of https://httpd.apache.org/docs/2.4/mod/mod_brotli.html#page-header
but a) I think it would be best to then have it commented out i.e.
provided only as an example, and b) it might be better to try refine
scenarios that are reliable to enable by default (e.g. content below
/usr/share/javascript that we can cover by a policy) and then provide as
a separate conf snippet _not_ commented out and maybe even enabled by
default.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+QRkcACgkQLHwxRsGg
ASGN6w/9EmEXUsdQQ8JBmhnRPIiE2fn0DzLh5WQvQhiiirzy7ngSQrVcHhN2/v2o
TBGQrjr/n4uyqMsgdR6llSR4y8Ed7V0r+ECmIPEjR5NXAt9avgRv37WhBtH/r5Bf
2EYW5LHFAqIPSqQAlNBtembUMFafLA8RBcIG9Otl0S1KYzVKKjcRsNWv3NwZExNp
CPe/fHwZ1L+VJY+oKG4d1GVYZyyY+YVxfmtfzwGfcrgN7ncghAgARyTAYj7DneCa
GuOiGqj8X1IihZ4rokQ6AfV2aFxhPIZwts1VYbBP2/o34udLHKM/XWIEBPScY7Gs
5PCyt3JIb/VtzNYW5xLItZolwDqOkro1rbrlcPZwmJHGXF4cuqrvau9WzRXCpk+b
1gEy4rPS8hc1GdISA2Fx5ueWckLYrqQYqFzUgb8pKqtd0pKEofnkNJu1QVSVMhvJ
obSW2DGNgSUBMRxTqk/FYBngX4KWV+GcflWDkgdvjWV+gSNvAIx/iFbOhmgvNFMW
9v0PH5hThUtvV5OmVrIFTpXD/6x7JCU/Pd6cJoiT7wY0scF6VEgkGqKjEhziJIJw
/3iuFsGgIzC9hAFh7EvzYXD7Ucc7WjiPeurTzzwT0Ypu86FyVLxhyMEEZzfwrC3i
Ft7k+XjXzgiourUVFkF+Y2wLYXeJLjzm+elUMIvDadvZsRUINbE=
=6F6H
-----END PGP SIGNATURE-----


Reply to: