This is inspired from the recent work to support etags for NixOS. We've also started switching many of our builds to being fully reproducible (including stripping timestamps) and this does not play well with Caddy and etags.

I assume that the reason for not hashing files to generate the etag is because of how expensive that would be on every request. A better solution I think would be to add a new option to the file_server directive to read the etag from a file in the same directory with the same name but with an arbitrary suffix, similar to how the brotli, gzip, and zstd compression directives will serve a pre-compressed file if it exists in the same directory with the appropriate suffix (.br etc). This file could be pre-computed in advance by whatever build infrastructure the user uses.

I propose that the end user be allowed to choose the suffix so that it can fit with whatever algorithm they use. For example, the following should be valid directory contents (using .b3sum as the suffix matching the extremely quick BLAKE3 algorithm):

index.html
index.html.b3sum
index.html.br
index.html.br.b3sum
favicon.ico
favicon.ico.b3sum
favicon.ico.br
favicon.ico.br.b3sum

With the correct configuration Caddy would read the contents of the .b3sum file and set the etag header to that value for the request. Because these files are typically extremely small this should be a very cheap operation, and for a particularly busy server it is likely that they would all end up in the page cache.