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,
Hi Guilhem, Quoting Guilhem Moulin (2021-01-12 18:42:39) 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
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]. 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. Please at least document the extension change in the NEWS files, as the change might require a manual configuration update on the HTTPd.
Quoting Guilhem Moulin (2021-01-12 21:30:43) Heh - developed by Google I am not surprised they have their own agenda. Sorry, I found some evidence but don't recall if it was substantion and failed at locating it again now :-) 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 remember seeing such debate - but apparently another than the toothless "debate" at [0] which does not mention ISO 639-1 at all. 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
Quoting Jonas Smedegaard (2021-01-12 21:50:19) 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") 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 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
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-seeme cu 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-container sc st Southern Sotho | application/vnd.sailingtracker.track st 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-realaudio ra rm ram sd Sindhi | chemical/x-mdl-sdfile sd sdf sw Swahili | chemical/x-swissprot sw 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/dv dif dv gl Galician | video/gl gl 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-perl pl 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.graphviz gv
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?
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/ecmascript es
application/vnd.msa-disk-image msa
application/vnd.sigrok.session sr
application/vnd.snesdev-page-table ptrom pt
#text/troff t tr roff
text/vnd.wap.si si
text/vnd.wap.sl sl
(For es and tr the AddLanguage is preceded by a RemoveType with a
comment indicating it's precisely done to solve the conflict.)
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]
<FilesMatch "\.js\.brotli$">
Header append Content-Encoding br
[…]
</FilesMatch>
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.
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 <FilesMatch/> of a system-provided snippet would be an OK
workaround, but whatever, I guess using .brotli suffixes for apache2 is
fine too :-)
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).
:-]
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) 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. Correct. That is a separate issue independent of the choice of file suffix for brotli, however. 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. 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. 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. 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
Hi Jonas,
Thanks for the feedback, I appreciate the discussion : -)
Please bear with me as I'm not an apache wizard, but that's not what I
had in mind. AFAICT the stock configuration comes with AddEncoding
mappings for neither .gz nor .br, but with ‘AddType application/gzip
.gz’ and ‘AddLanguage br .br’. So apache2 might serve files ending in
.gz and .br when content negotiation is enabled (when the HTTP request
has a ‘Accept-Type: application/gzip’ and/or ‘Accept-Language: br’
header respectively). That's the default config, and if the httpd
administrator wants to change the mapping so .gz files are served for
‘Accept-Encoding: gzip’ instead, then they have to use ‘RemoveType .gz’
first. Why treat .br differently? As long as the stock config doesn't
come with ‘AddEncoding gzip .gz’ and ‘AddEncoding br .br’ there are no
conflicts and I don't see the need for a NEWS entry.
Furthermore the apache2 configuration we currently ship doesn't include
serving precompressed files depending on the value of the Accept-Encoding
header, so I'm not sure the apache2 package is the place to submit that
question. In #972632 you suggested shipping the relevant configuration
snippet, and enabling it for /javascript or similar. I suppose that
involves changing the mapping for .gz right (or disabling content
negotation altogether and use mod_rewrite instead, since the directory
also includes a .min.js file) right? I don't see what's controversial
about changing mappings, be it for .gz or .br, as long as the scope is
*limited to namespaces you control*. I wasn't advocating for gobal
removal of existing .gz/.br mappings, so no need to ask Breton folks to
rename their documents :-)
Finally the “we decided” sounds a bit far fetched to me; for better or
worse the brotli(1) utility defaults to .br suffix. So when someone
runs `find /var/www/html -type f -exedir brotli -k -- {} +` to
statically compress their pages they'll end up with .br files. Other
tools settled on that extension too, and apache2 own documentation for
mod_brotli has .br in its configuration snippets as well. Moreover
Debian ships with other HTTPd; I don't know if the suffix is
configurable in lighttpd but I hope to see ngx_http_brotli_static_module
land into Debian at some point, and it unfortunately hardcodes the
suffix to .br (like ngx_http_gzip_static_module hardcodes .gz). All in
all, if we settle on another suffix, then it'll actually be *us*
deciding to diverge from upstream, and likely not in a consistent
fashion.
Appologies for insisting, but why is the *potential* conflict (the stock
configuration is conflict free since AddEncoding mappings are disabled)
for .gz not a problem then? Globally removing the Type mapping isn't an
option because that will break default Content-Type response headers, so
if I follow your logic right you also need to rename jquery.min.js.gz to
jquery.min.js.gzip so local administators can save the ‘RemoveType .gz’
and get away with a mere ‘AddEncoding gzip .gzip’. Is there a double
standard I don't follow, or something else I'm missing here?
Ack, I agree there is less potential to shoot oneself in the foot of
course. But as far as libjs-query is concerned we're talking about
.min.js.br(otli), not about adding new httpd configuration snippet under
te hood. If the mere presence of a .min.js.br file — in a namespace
under the Javascript Maintainers' control — is a blocker because it
might break existing setups, then one could argue it's even safer to
drop or rename the .gz as well, because it breaks setups where
GET /path/to/file.js HTTP/1.1
Accept: */*
yields
HTTP/1.1 200 OK
Content-Location: file.js.gz
Content-Type: application/x-gzip
when $documentroot/path/to/file.js.gz exists on disk and
HTTP/1.1 200 OK
Content-Location: file.js
Content-Type: application/javascript
when it does not. That's perfectly valid as far as content negotation
is concerned, not even that far fetched: consider for instance a service
regularily compressing log files and exposing them to the web (so the
client can download uncompressed or gzipped files), and a rewrite rule
checking for the presence of $file.gz where the $URI =~ /\.log$/ guard
was forgotten. That service worked with Stretched and broke with
Buster. Is the solution really to use non-“standard” suffixes for
precompressed files? That's not what the various upstream projects are
suggesting AFAICT.
We don't need to speculate here, Buster's libjs-jquery has .gz and .br
compressed files alongside the minified Javascript. Has anyone
complained about this? :-) Unfortunately .br maps to Breton not
Brazilian Portugese which has a few orders of magnitude more speakers;
the absence of bug reports does not mean that all is well but it's an
indication nonetheless.
Choosing another extension unfortunately means that static compression
might not be usable with other HTTP daemons without diversion or manual
symlink dance. :-(
Dzień dobry, kontaktuję się z Państwem, ponieważ dostrzegam możliwość redukcji opłat za prąd. Odpowiednio dobrana instalacja fotowoltaiczna to rozwiązanie, które pozwala wygenerować spore oszczędności w skali roku. Chciałbym porozmawiać z Państwem o tego typu rozwiązaniu, a także przedstawić wstępne kalkulacje. Czy są Państwo zainteresowani? Pozdrawiam, Dorian Kwiatkowski
Dzień dobry, kontaktuję się z Państwem, ponieważ dostrzegam możliwość redukcji opłat za prąd. Odpowiednio dobrana instalacja fotowoltaiczna to rozwiązanie, które pozwala wygenerować spore oszczędności w skali roku. Chciałbym porozmawiać z Państwem o tego typu rozwiązaniu, a także przedstawić wstępne kalkulacje. Czy są Państwo zainteresowani? Pozdrawiam, Dorian Kwiatkowski
Dzień dobry, jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google. Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów. Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę? Pozdrawiam serdecznie, Patryk Górecki
Dzień dobry, jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google. Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów. Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę? Pozdrawiam serdecznie, Patryk Górecki
Dzień dobry, jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google. Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów. Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę? Pozdrawiam serdecznie, Patryk Górecki
Dzień dobry, jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google. Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów. Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę? Pozdrawiam serdecznie, Patryk Górecki
Dzień dobry! Czy mógłbym przedstawić rozwiązanie, które umożliwia monitoring każdego auta w czasie rzeczywistym w tym jego pozycję, zużycie paliwa i przebieg? Dodatkowo nasze narzędzie minimalizuje koszty utrzymania samochodów, skraca czas przejazdów, a także tworzenie planu tras czy dostaw. Z naszej wiedzy i doświadczenia korzysta już ponad 49 tys. Klientów. Monitorujemy 809 000 pojazdów na całym świecie, co jest naszą najlepszą wizytówką. Bardzo proszę o e-maila zwrotnego, jeśli moglibyśmy wspólnie omówić potencjał wykorzystania takiego rozwiązania w Państwa firmie. Z poważaniem, Dawid Rowicki
Dzień dobry! Czy mógłbym przedstawić rozwiązanie, które umożliwia monitoring każdego auta w czasie rzeczywistym w tym jego pozycję, zużycie paliwa i przebieg? Dodatkowo nasze narzędzie minimalizuje koszty utrzymania samochodów, skraca czas przejazdów, a także tworzenie planu tras czy dostaw. Z naszej wiedzy i doświadczenia korzysta już ponad 49 tys. Klientów. Monitorujemy 809 000 pojazdów na całym świecie, co jest naszą najlepszą wizytówką. Bardzo proszę o e-maila zwrotnego, jeśli moglibyśmy wspólnie omówić potencjał wykorzystania takiego rozwiązania w Państwa firmie. Z poważaniem, Dawid Rowicki
Dzień dobry! Czy mógłbym przedstawić rozwiązanie, które umożliwia monitoring każdego auta w czasie rzeczywistym w tym jego pozycję, zużycie paliwa i przebieg? Dodatkowo nasze narzędzie minimalizuje koszty utrzymania samochodów, skraca czas przejazdów, a także tworzenie planu tras czy dostaw. Z naszej wiedzy i doświadczenia korzysta już ponad 49 tys. Klientów. Monitorujemy 809 000 pojazdów na całym świecie, co jest naszą najlepszą wizytówką. Bardzo proszę o e-maila zwrotnego, jeśli moglibyśmy wspólnie omówić potencjał wykorzystania takiego rozwiązania w Państwa firmie. Z poważaniem, Dawid Rowicki
Dzień dobry, czy interesuje Państwa wymiana niezapłaconych przez Klientów faktur na gotówkę? Pomagamy wszystkim przedsiębiorcom, którzy szukają gwarancji bezpieczeństwa i płynności finansowej. Jeśli są Państwo otwarci na wstępną rozmowę w tym temacie proszę o odpowiedź. Pozdrawiam, Adrian Ostojski Dyrektor Finansowy
Dzień dobry, zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów. Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci. Możemy porozmawiać w najbliższym czasie? Pozdrawiam Adam Furgalski
Dzień dobry, kontaktuje się z Państwem, ponieważ jako osoba zajmująca się usprawnieniem procesów, chciałbym zaprezentować nowoczesne rozwiązanie dla Państwa firmy. System został stworzony z myślą o przedsiębiorstwach z sektora MŚP, aby zapewnić bezpieczeństwo danych, niezawodność i optymalizację procesów. Dzięki bogatym funkcjonalnościom usprawnia i przyspiesza obsługę zleceń. Jeśli chcieliby Państwo zwiększyć tempo rozwoju swojej działalności i poszerzyć rynek zbytu chętnie opowiem więcej. Kiedy mogę się skontaktować? Pozdrawiam, Arkadiusz Stryj
Dzień dobry, zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów. Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci. Możemy porozmawiać w najbliższym czasie? Pozdrawiam Adam Furgalski