"precompressed" files without "base" files?

[TobiX (Tobias Gruetzmacher)]

1. Output of caddy version:

v2.6.1 h1:EDqo59TyYWhXQnfde93Mmv4FJfYe00dO60zMiEt+pzo=

2. How I run Caddy:

Debian package, via default systemd unit.

a. System environment:

b. Command:

systemctl start caddy

d. My complete Caddy config:

int.server.company.bogus {
	root * /srv/www

	tls /etc/ssl/private/snakeoil-cert.pem /etc/ssl/private/snakeoil-key.pem

	handle_path /sites* {
		root * /srv/data/sites

		@css path *.css
		header @css Content-Type text/css
		@svg path *.svg
		header @svg Content-Type image/svg+xml
		@js path *.js
		header @js Content-Type text/javascript
		@html path *.html *.htm
		header @html Content-Type text/html

		@has_gzip file {path}.gz
		handle @has_gzip {
			header Content-Encoding gzip
			rewrite {http.matchers.file.relative}
		}

		file_server browse
	}

	file_server
}

3. The problem I’m having:

I have a big collection of quite compressible files, which aren’t changed that often. Therefore it would be nice to just save them compressed and have caddy serve them as either compressed or uncompressed (if the client really doesn’t support compressed respones). Currently, when running a caddy fileserver with the precompressed option, caddy only delivers the compressed variants of a file if the uncompressed file also exists…

(Currently, I’m helping myself with a more complex configuration inspired by Why caddy 2 is not able to serve static brotli files? - #28 by Whitestrake - It is lacking a bit, since it won’t serve clients without gzip support)

6. Links to relevant resources:

Since I was migrating from nginx, which has this feature, here is a reference on how this works on nginx:

• Module ngx_http_gzip_static_module
• Module ngx_http_gunzip_module

[matt (Matt Holt)]

Could you open an issue to request this feature? Sign in to GitHub · GitHub

Thanks!

[francislavoie]

We implemented it this way because we only look for a precompressed file after finding that the main file exists, to avoid doing multiple filesystem calls when requesting files that don’t exist (which would hurt performance when under heavy load). Also, the Accept-Encoding header is optional, so it would be awkward to only be able to serve the file if the header is specified.

I realize that’s not what you want to hear, but it’s a compromise. Most of the time, both need to exist for things to work properly. There might be a way we can add an option to not check for the primary file though, so like Matt said, open an issue on Github

[Whitestrake (Matthew Fay)]

Yeah, I think since it’s the client’s option to accept encoding, for compatibility sake it makes sense by default to serve a compressed version of an existing file in case the encoded version isn’t accepted, right? So the current behavior seems right to me, but I imagine an option to change that to accommodate this use case on the user’s option also makes sense.

All discussable on the Github once an issue is open.

[matt (Matt Holt)]

I think that’s the point of the gunzip feature in Nginx, us to decompress the file for clients that don’t accept the encoding.

But yeah, the question is, to assume decompressed, or compressed?

Tbf most clients accept compression these days, so I can understand wanting that to be the default.