Hi Jonas,
Thanks for the feedback, I appreciate the discussion : -)
On Wed, 13 Jan 2021 at 13:20:17 +0100, Jonas Smedegaard wrote:
> 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".
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.
> ...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.
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?
> 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
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.
> 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.
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.
> 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.
Choosing another extension unfortunately means that static compression
might not be usable with other HTTP daemons without diversion or manual
symlink dance. :-(
--
Guilhem.
Attachment:
signature.asc
Description: PGP signature