ETag and HTTP Caching

1. hashfs

   1 4 371 2.6 Go

   Implementation of io/fs.FS that appends SHA256 hashes to filenames to allow for aggressive HTTP caching.

   

   An approach like https://github.com/benbjohnson/hashfs allows file names to be updated at runtime to be content hashed. This removes the need for the extra "304 Not Modified" API calls from the client. This content hash based file renaming is usually done using a build step which renames files. For applications where the static file serving and HTTP request processing are done in the same application, this can be done in memory without a build step for file renames.

   I am using that approach in my project https://github.com/claceio/clace. It removes the need for a build step while making aggressive static file caching possible.

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. clace

   2 34 607 9.6 Go

   Application server for deploying containerized web apps. Easily deploy internal tools across a team.

   

   An approach like https://github.com/benbjohnson/hashfs allows file names to be updated at runtime to be content hashed. This removes the need for the extra "304 Not Modified" API calls from the client. This content hash based file renaming is usually done using a build step which renames files. For applications where the static file serving and HTTP request processing are done in the same application, this can be done in memory without a build step for file renames.

   I am using that approach in my project https://github.com/claceio/clace. It removes the need for a build step while making aggressive static file caching possible.

4. xtemplate

   3 3 76 6.9 Go

   A html/template-based hypertext preprocessor and rapid application development web server written in Go. (by infogulch)

   

   I've also been dissatisfied with http caching not utilizing content hashes enough. If you're using server side templating one issue is that it's not efficient to calculate the hash while you're running the template, it would need to be precalculated to be efficient enough to use.

   So I wrote https://github.com/infogulch/xtemplate to scan all assets at startup to precalculate the hash for templates that use it, and if a request comes in with a query parameter ?hash=sha384-xyz and it matches then it gives it a 1 year immutable Cache-Control header automatically. If a file x.ext has a matching x.ext.gz/x.ext.zst/x.ext.br file then (after hashing the content to make sure it matches) client requests that support it are sent a compressed version streamed directly from disk with sendfile2. I call this "Optimal asset serving" (a bit bold perhaps).

5. xxHash

   4 30 9,840 9.0 C

   Extremely fast non-cryptographic hash algorithm

   

Suggest a related project