[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Jonas Smedegaard]

reassign 979996 apache2
retitle 979996 apache2: should we use .br or .brotli as suffix for precompressed brotli files?
affects 979996 + civicrm-common libjs-backbone libjs-bootbox libjs-janus libjs-jquery libjs-json libjs-leaflet libjs-leaflet-image libjs-leaflet.markercluster libjs-node-forge libjs-olm libjs-qunit libjs-rdf-canonize libjs-sdp libjs-trust-json-document libjs-uglify-js libjs-webrtc-adapter libjs-underscore libjs-terser libjs-rtcpeerconnection-shim libjs-n3 libjs-jsonld libjs-functional-red-black-tree libjs-flatted
thanks

This issue is not specific to libjs-jquery, so reassigning to default 
web server in Debian, Apache2.

Quoting Guilhem Moulin (2021-01-13 04:55:45)
> Had a closer look at this with the help of your links from msg#27.  With
> both foo.css.gz and foo.css.br present in a directory, .gz and .br
> respectively mapping to gzip and br encoding (and .br to the breton
> language too), as Kevin wrote the request fails:
> 
>     HEAD /foo.css HTTP/1.1
>     Accept: */*
>     Accept-Encoding: br
>     Accept-Language: en
> 
>     HTTP/1.1 406 Not Acceptable
>     Date: Wed, 13 Jan 2021 03:06:33 GMT
>     Server: Apache/2.4.46 (Debian)
>     Alternates: {"foo.css.br" 1 {type text/css} {language br} {encoding br} {length 3}}, {"foo.css.gz" 1 {type text/css} {encoding gzip} {length 32}}
>     Vary: negotiate,accept-language,accept-encoding
>     TCN: list
>     Content-Type: text/html; charset=iso-8859-1
> 
> However I still don't understand why this is a blocker.  With the 
> MultiViews method one accepts to use ‘RemoveType .gz’, why is it not 
> OK to use ‘RemoveLanguage .br’?

Use of language codes as file suffix is in active use and predates the 
introduction of the brotli compression format.

I find it wrong for Debian to add a NEWS file of "hi all brazilians, we 
decided that expressing the hip new brotli compression a few letters 
shorter is more important for us than support for your language - please 
either rename all your localized documents or locally disable that hip 
new compression format".

I find it comparable to other name spaces in Debian, where we a) are 
conservative (something older has priority over something new) and b) we 
deviate from upstream naming when needed to fit multiple things in same 
namespace concurrently.


> Also, the MultiViews method won't work with 
> /usr/share/javascript/jquery anyway because jquery.min.js exists, so 
> apache2 won't honor Content- {Language,Encoding} negotiation and serve 
> that file instead (ie never pick the compress files from the file 
> system), right?

Correct.  That is a separate issue independent of the choice of file 
suffix for brotli, however.


> The mod_brotli configuration snippet you linked to in #972632 works 
> well on the other hand.  Using mod_rewrite one can emulate negotiation 
> and point the HTTPd to the uncompressed / gzipped / brotli-compressed 
> file depending on the value of the ‘Accept-Encoding’ header.  When 
> using .br suffixes the file is served with ‘Content-Language: br’ 
> header, which I guess is why you changed the extension?  IMHO adding 
> ‘RemoveLanguage .br’ in the <FilesMatch/> of a system-provided snippet 
> would be an OK workaround, but whatever, I guess using .brotli 
> suffixes for apache2 is fine too :-)

mod_rewrite is considered a powertool too heavy/complex/dangerous for 
ordinary sysadmins.  See e.g. 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64372

...and again, concrete implementations of how to do content negotiation 
based on file suffix really is ortogonal to the issue of clashing 
interpretation of one specific file extension.


> On Tue, 12 Jan 2021 at 23:32:29 +0100, Guilhem Moulin wrote:
> > Keeping the above snippet, would apache complain about the mere 
> > presence of a jquery.min.js.br file alongside the 
> > jquery.min.js.brotli?

I did not test any concrete implementation.

I have experience with content-negotiation for choosing language.

I am confident that files written in Brazilian Portuguese and saved with 
extension .br.html or .html.br will continue to be served as intented 
even with the introduction of .brotli files, with _all_ Apache2 
configurations (except flawed ones using non-terminated regular 
expression, most likely due to mod_rewrite confusion).

I am also confident that some of those existing setups will break if 
files are introduced with suffix .br which are *not* brazilian 
Portuguese but instead are compressed with brotli compression.

I.e. I consider it a bug to ship web-related files in Debian with suffix 
.br which do not contain brazilian portuguese variant of same file 
without that suffix or with different suffix.  Debian contain a few such 
packages¹, which I introduced, and I will now fix those by renaming that 
wrong suffix to .brotli to avoid that clash.


> Given Content-{Language,Encoding,Type,…} is unusable here (because the 
> uncompressed file is present as well), I was unable to find any 
> downside of doing that (aside from the fact that symlink resolution 
> now needs to be enabled).

Sorry, I lost you - what has no downsides (that you know of)?

If you mean a specific Apache2 configuration, then beware that Debian 
users already for many years serve content with a behaviour of 
auto-resolving .br as meaning Brazilian Portuguese, so introducing some 
specific custom configuration snippet to distinguish 
in-this-context-interpret-as-locale from 
in-this-context-interpret-as-compression will *break* existing user 
setups, whereas using .brotli for compression will not break anything.


> > If not, then how about shipping both?

Shipping brotli-compressed content as both .br and .brotli files will 
clash with Brazilian Portuguese files using same file suffix for a 
different purpose.


 - Jonas


¹ Thise packages in sid currently contain web-exposed .br files which 
contains brotli-compressed content: libjs-underscore libjs-terser 
libjs-rtcpeerconnection-shim libjs-n3 libjs-jsonld libjs-funct 
ional-red-black-tree libjs-flatted

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20210113/9b4cc7a9/attachment.sig>