[Pkg-javascript-devel] Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files
Guilhem Moulin
guilhem at debian.org
Tue Jan 12 22:32:29 GMT 2021
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/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.)
> 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]
<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.
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20210112/6177e068/attachment.sig>
More information about the Pkg-javascript-devel
mailing list