[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
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 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
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
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’?
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?
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 of a system-provided snippet would be an OK
workaround, but whatever, I guess using .brotli suffixes for apache2 is
fine too :-)
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?
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).
> If not, then how about shipping both?
:-]
--
Guilhem.
signature.asc
Description: PGP signature
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
On Tue, 12 Jan 2021 at 22:35:30 +0100, Jonas Smedegaard wrote: > * rfc7932 refrain from recommending a suffix > (only talks about "HTTP Content Coding Registry") That RFC is beyond my head but quick searches for “suffix” and “extension” didn't lead to meaningful results. The IANA registration is only for Accept-Encoding HTTP request headers so irrelevant as far as files are concerned, no? >>> br is the ISO 639-1 code for the breton language but I guess that's >>> not what you mean (application/ecmascript, text/x-perl or video/gl >>> don't conflict with the language codes for Spanish, Polish or >>> Galician right)? After quick search I was unable to find an >>> official registration for the .br file suffix. >> >> As I recall, the "officiality" of it is tied to that ISO 639-1 and >> some W3C definitions (but might just be recommendations, and might >> just be Apache2 practise). > > More specifically, Apache2 by default follows RFC 3066: > https://httpd.apache.org/docs/current/mod/mod_mime.html#addlanguage > > ...and encourages using both language codes and media types (e.g. a > JavaScript file pre-compressed using brotli) and handlers (e.g. > on-the-fly request for brotli-compression when serving a JavaScript > file), and warns about clashes between those: > https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext Oh I see, thanks for the links. My Apache2-fu is a bit rusty :-P So what matters isn't the ISO 639-1 conflict per se, but rather the presence of the AddLanguage with a suffix that's also used for a file extension? Then I note that a stock apache2/media-type comes with conflicts for #application/ecmascriptes application/vnd.msa-disk-image msa application/vnd.sigrok.session sr application/vnd.snesdev-page-table ptrom pt #text/trofft tr roff text/vnd.wap.sisi text/vnd.wap.slsl (For es and tr the AddLanguage is preceded by a RemoveType with a comment indicating it's precisely done to solve the conflict.) > The debate I saw was Mozilla (referenced from above kevinlocke page): > https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147 > > ...but really that discussion ended without deciding on a file > extension, probably because Firefox does not need that at all. Indeed. In the end I don't care either which suffix is used, but would like to have something that also works when ngx_brotli enters Debian (I don't know what's the status of static compression with other HTTPd, and if the file extension is configurable). So I understand from #972632 that you're suggesting to ship a snippet such as RewriteRule "^(.*)\.js" "$1\.js\.brotli" [QSA] RewriteRule "\.js\.brotli$" "-" [T=text/javascript,E=no-brotli:1] Header append Content-Encoding br […] This would not conflict with the ‘AddLanguage br .br’ directive, and also play well with the .brotli suffix that jquery is now using. Keeping the above snippet, would apache complain about the mere presence of a jquery.min.js.br file alongside the jquery.min.js.brotli? If not, then how about shipping both? That's what I meant by compatibility symlink in my original message. That setup would play well with ngx_brotli also, if symlink resolution is enabled. It might also be helpful for those who copy configuration snippets mentioning .br not .brotli. -- Guilhem. signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
On Tue, 12 Jan 2021 at 21:50:19 +0100, Jonas Smedegaard wrote: >> br is the ISO 639-1 code for the breton language but I guess that's >> not what you mean (application/ecmascript, text/x-perl or video/gl >> don't conflict with the language codes for Spanish, Polish or Galician >> right)? After quick search I was unable to find an official >> registration for the .br file suffix. > > As I recall, the "officiality" of it is tied to that ISO 639-1 and some > W3C definitions (but might just be recommendations, and might just be > Apache2 practise). I'm rather suprised by this, matching the 184 ISO 639-1 codes against a stock mime.types from media-types 3.0.0 I find 23 conflicts (16 if we exclude the /x- MIME types): cu Church Slavic| application/cu-seemecu es Spanish | application/ecmascript es nb Norwegian Bokmål | application/mathematica nb ma mb nbp ps Pushto | application/postscript ps ai eps epsi epsf eps2 eps3 sc Sardinian| application/vnd.ibm.secure-containersc st Southern Sotho | application/vnd.sailingtracker.trackst sr Serbian | application/vnd.sigrok.session sr pt Portuguese | application/vnd.snesdev-page-table ptrom pt fo Faroese | application/vnd.software602.filler.form+xml fo sm Samoan | application/vnd.stepmania.stepchart sm ms Malay| application/x-troff-ms ms rm Romansh | audio/x-pn-realaudiora rm ram sd Sindhi | chemical/x-mdl-sdfile sd sdf sw Swahili | chemical/x-swissprotsw tr Turkish | text/troff t tr roff gv Manx | text/vnd.graphviz gv dot ts Tsonga | text/vnd.trolltech.linguist ts si Sinhala | text/vnd.wap.si si sl Slovenian| text/vnd.wap.sl sl pl Polish | text/x-perl pl pm tk Turkmen | text/x-tcl tcl tk dv Divehi | video/dvdif dv gl Galician | video/glgl HTTP daemons may ignore our /etc/mime.types, but as of nginx 1.18.0-6 from sid the default config has conflicts for ps Pushto | application/postscript ps ai eps epsi epsf eps2 eps3 pl Polish | text/x-perlpl pm AFAICT Debian's apache uses /etc/mime.types by default (so the above applies), but docs/conf/mime.types from the source tree has conflicts for cu Church Slavic| application/cu-seeme cu nb Norwegian Bokmål | application/mathematica nb ma mb so Somali | application/octet-stream bin dms lrf mar so dist distz pkg bpk dump elc deploy ps Pushto | application/postscript ai eps ps sc Sardinian| application/vnd.ibm.secure-container sc rm Romansh | application/vnd.rn-realmedia rm st Southern Sotho | application/vnd.sailingtracker.track st sm Samoan | application/vnd.stepmania.stepchart sm tr Turkish | text/troff t tr roff man me ms gv Manx | text/vnd.graphvizgv -- Guilhem. signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
Quoting Jonas Smedegaard (2021-01-12 21:50:19) > Quoting Guilhem Moulin (2021-01-12 21:30:43) > > On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote: > > > The officially registered meaning for file suffix .br is the > > > language breton. > > > > Do you have a link for this? > > Sorry, I found some evidence but don't recall if it was substantion > and failed at locating it again now :-) Found now what convinced me to use .brotli instead of .br: https://kevinlocke.name/bits/2016/01/20/serving-pre-compressed-files-with-apache-multiviews/#adding-brotli Boils down to... * Apache2 already by default use ISO 639-1 suffices (so "just" a well-stablished default, no official standard) * rfc7932 refrain from recommending a suffix (only talks about "HTTP Content Coding Registry") > > br is the ISO 639-1 code for the breton language but I guess that's > > not what you mean (application/ecmascript, text/x-perl or video/gl > > don't conflict with the language codes for Spanish, Polish or > > Galician right)? After quick search I was unable to find an > > official registration for the .br file suffix. > > As I recall, the "officiality" of it is tied to that ISO 639-1 and > some W3C definitions (but might just be recommendations, and might > just be Apache2 practise). More specifically, Apache2 by default follows RFC 3066: https://httpd.apache.org/docs/current/mod/mod_mime.html#addlanguage ...and encourages using both language codes and media types (e.g. a JavaScript file pre-compressed using brotli) and handlers (e.g. on-the-fly request for brotli-compression when serving a JavaScript file), and warns about clashes between those: https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext > > It appears there was some debate upstream about the default > > extension (.br / .bro / .brotli) [0,1] but they now settled on .br > > and I think it's unfortunate to choose something else, especially > > given this not configurable everywhere. > > I remember seeing such debate - but apparently another than the > toothless "debate" at [0] which does not mention ISO 639-1 at all. The debate I saw was Mozilla (referenced from above kevinlocke page): https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147 ...but really that discussion ended without deciding on a file extension, probably because Firefox does not need that at all. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
Quoting Guilhem Moulin (2021-01-12 21:30:43) > On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote: > > I think you (and nginx?) are mistaken: > > FWIW ngx_brotli is a third-party nginx module developed by the folks > (Google) behind the brotli(1) utility and the brotli data format > [RFC7932]. Heh - developed by Google I am not surprised they have their own agenda. > > The officially registered meaning for file suffix .br is the > > language breton. > > Do you have a link for this? Sorry, I found some evidence but don't recall if it was substantion and failed at locating it again now :-) > br is the ISO 639-1 code for the breton language but I guess that's > not what you mean (application/ecmascript, text/x-perl or video/gl > don't conflict with the language codes for Spanish, Polish or Galician > right)? After quick search I was unable to find an official > registration for the .br file suffix. As I recall, the "officiality" of it is tied to that ISO 639-1 and some W3C definitions (but might just be recommendations, and might just be Apache2 practise). > It appears there was some debate upstream about the default extension > (.br / .bro / .brotli) [0,1] but they now settled on .br and I think > it's unfortunate to choose something else, especially given this not > configurable everywhere. I remember seeing such debate - but apparently another than the toothless "debate" at [0] which does not mention ISO 639-1 at all. > > Until that clash with language code is resolved (if ever) I think it > > is wrong to change back, and I therefore flag this as wontfix. > > Please at least document the extension change in the NEWS files, as > the change might require a manual configuration update on the HTTPd. Ah, I thought it was introduced recently, even with the old suffix, but I see now that it was in buster. Yes, makes sense to add a NEWS entry for that. Thanks! - Jonas > [0] https://github.com/google/brotli/issues/299 > [1] https://news.ycombinator.com/item?id=11336756 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote: > I think you (and nginx?) are mistaken: FWIW ngx_brotli is a third-party nginx module developed by the folks (Google) behind the brotli(1) utility and the brotli data format [RFC7932]. > The officially registered meaning for file suffix .br is the language > breton. Do you have a link for this? br is the ISO 639-1 code for the breton language but I guess that's not what you mean (application/ecmascript, text/x-perl or video/gl don't conflict with the language codes for Spanish, Polish or Galician right)? After quick search I was unable to find an official registration for the .br file suffix. It appears there was some debate upstream about the default extension (.br / .bro / .brotli) [0,1] but they now settled on .br and I think it's unfortunate to choose something else, especially given this not configurable everywhere. > Until that clash with language code is resolved (if ever) I think it is > wrong to change back, and I therefore flag this as wontfix. Please at least document the extension change in the NEWS files, as the change might require a manual configuration update on the HTTPd. -- Guilhem. [0] https://github.com/google/brotli/issues/299 [1] https://news.ycombinator.com/item?id=11336756 signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
Control: tags -1 +wontfix Hi Guilhem, Quoting Guilhem Moulin (2021-01-12 18:42:39) > Package: libjs-jquery > Version: 3.5.1+dfsg+~3.5.5-5 > Severity: normal > > Dear Maintainer, > > The brotli suffix was changed from .br to .brotli in > 3.5.1+dfsg+~3.5.4-3: > > > https://salsa.debian.org/js-team/node-jquery/-/commit/2c27f2b80e89dc4fb051cb7081ad464643316a9d > > The .br suffix is hardcoded in ngx_http_brotli_static_module (granted > ngx_brotli is not in Debian at the moment, #919320) — just like .gz is > hardcoded in ngx_http_gzip_static_module — so the precompressed > .brotli resources aren't usable by Nginx. > > Given .br is the default suffix for brotli files, please consider > reverting the above change, or at least providing compatibility > symlinks. I think you (and nginx?) are mistaken: The officially registered meaning for file suffix .br is the language breton. The confusion probably stems from the (officially registered, I guess) content-encoding type 'br' which indeed is brotli. I introduced the brotli-compressed files with extension .br but changed that when I realized my mistake. Until that clash with language code is resolved (if ever) I think it is wrong to change back, and I therefore flag this as wontfix. See also related bug#972632 from when I realized my mistake. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
Package: libjs-jquery Version: 3.5.1+dfsg+~3.5.5-5 Severity: normal Dear Maintainer, The brotli suffix was changed from .br to .brotli in 3.5.1+dfsg+~3.5.4-3: https://salsa.debian.org/js-team/node-jquery/-/commit/2c27f2b80e89dc4fb051cb7081ad464643316a9d The .br suffix is hardcoded in ngx_http_brotli_static_module (granted ngx_brotli is not in Debian at the moment, #919320) — just like .gz is hardcoded in ngx_http_gzip_static_module — so the precompressed .brotli resources aren't usable by Nginx. Given .br is the default suffix for brotli files, please consider reverting the above change, or at least providing compatibility symlinks. Cheers, -- Guilhem. signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
