Caddy’s wasteful partial serving
Post #16 published on by Tobias Fedder
Over a year ago I wrote My wasteful cacheless serving describing how I finally added Cache-Control to my Caddyfile (that being the configuration file for my favorite webserver Caddy). And how not setting it up had been somewhat wasteful until then in terms of unnecessary requests and therefore time and bandwidth spent. Now this post is about previous versions of Caddy undermining the effectiveness of my Cache-Control headers and my excitement that the newest release of Caddy fixes this.
What was the issue? So far my website is a completely static site. Meaning when you visit a page its content and its assets aren’t composed on request by the server (also known as server‐side rendering), but instead the server simply responds with the content of a corresponding file that I made in advance. Benefits of this approach are less computation on the server per request and a smaller attack surface because there is less server‐side logic / less software needed to respond to a request.
One of my favorite Caddy features is the precompressed directive. I wrote Minifying and compressing text files to reduce load about how I started using it. It allows me to put sidecar files next to their respective normal file. The difference being that each sidecar file is already compressed and has a suffix in its filename indicating the compression algorithm that was used. When a request comes in with a matching Accept-Encoding header Caddy responds with the compressed content from the sidecar file. Thereby, once again, reducing computation and time spent compared to compressing the content on‐the‐fly per request. Instead, the compression happens just once per generation of a static file at build time, way ahead of any request.
However, in recent versions of Caddy there has been an issue with the precompressed directive, leading to missing an empty byte in the response and returning the response with the status code 206 Partial Content. That in turn led to some browsers not caching the response. Probably to avoid headaches with different pieces of partial content in cache.
A fix for the issue itself was available quite soon. But the maintainers of this beautiful open‐source software did not see a need for a new release for a while. Sure, there is plenty of documentation and similar resources on how to build your own executable from the source. Though, if you’ve read a previous post of mine praising Caddy, that is mostly about ease of use. Cloning a repository, setting up build tools and the like, to build an executable of a webserver, in a state that the maintainers did not feel like releasing, and deploying that to a machine of mine, which is exposed to the internet — that doesn’t sound like ease of use. It sounds like I’m on my own in unknown territory. In other words: problems waiting to happen.
So I waited it out. Now a new version containing the fix has been released. Maybe we can call Caddy the ultimate server again, even if the goal is to serve cacheable precompressed static files.