ETag and HTTP Caching

This is nice. It reminds of how miserable my life is.<p>— Which HTTP code I should return for my API? I already used 404, 403, but I need another one. Damn, HTTP is so old and it makes no sense.<p>— You can&#x27;t use HTTP codes like that Bob, they&#x27;re not a free choice. They&#x27;re for the protocol, not for your app.<p>— Let&#x27;s look at the list. Hm... &quot;412 Precondition Failed&quot;. Hey, it sounds nice. It fits to my use case. I&#x27;m gonna document it. It means the account is out of balance.<p>— What is this garbage? Please read the spec. This is going to make our API gateways, CDNs, everything go crazy. Can&#x27;t let you move on with this PR.<p>— Look. I documented it, made an enum with the code, it&#x27;s clean. I&#x27;m an experienced REST developer.<p>— It... it doesn&#x27;t work like that Bob. Please, read the spec.<p>— Hey, got enough approvals, &quot;412 Account Out Of Balance&quot; it is! It passes the tests.<p>For each dev that knows proper HTTP, there&#x27;s 10.000 Bobs.

The ETag can be _anything_. I have an API that serves &quot;files&quot; from a backend storage system. Whenever files are written a revision number is incremented. This is perfect for a weak validator and so my ETags are also blisfully short and semantically useful, typically:<p><pre><code> ETag: W&#x2F;&quot;750&quot; </code></pre> This also means the API can just check the revision number and avoid pulling out and decompressing some of the larger payloads that are stored there and the implementation is absolutely minimal. It&#x27;s a great standard.

An approach like <a href="https:&#x2F;&#x2F;github.com&#x2F;benbjohnson&#x2F;hashfs">https:&#x2F;&#x2F;github.com&#x2F;benbjohnson&#x2F;hashfs</a> allows file names to be updated at runtime to be content hashed. This removes the need for the extra &quot;304 Not Modified&quot; 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.<p>I am using that approach in my project <a href="https:&#x2F;&#x2F;github.com&#x2F;claceio&#x2F;clace">https:&#x2F;&#x2F;github.com&#x2F;claceio&#x2F;clace</a>. It removes the need for a build step while making aggressive static file caching possible.

How is the sample `calculateETag()` function generating a weak ETag? It looks like it will generate a different hash due to any JSON formatting changes.<p>It seems like generating a weak ETag would take more effort since you&#x27;d need to either ensure consistent ordering and formatting of the JSON, or generate the Etag on the content before converting it to a JSON string.

I&#x27;ve not seen a very convincing use-case for ETags vs Last-Modified date caching.<p>In the example request, the server still has to do all of the work generating the page, in order to calculate the ETag and then determine whether or not the page has changed. In most situations, it&#x27;s simpler to have timestamps to compare against, because that gives the server a faster way to spot unmodified data.<p>e.g. you get a HTTP request for some data that you know is sourced from a particular file, or a DB table. If the client sends a If-Modified-Since (or whatever the header name is), you have a good chance to be able to check the modified time of the data source before doing any complicated data processing, and are able to send back a not modified response sooner.

I recently implemented this, great write-up. Regarding the hashing function, I’m curious about opinions. In my implementation I went for a cheap but weak cryptographic hash at first. Then I got worried that some auditor would flag it and time would be wasted convincing them to change their mind. But then I stumbled upon FNV [1], a non-cryptographic hash and part of Go’s standard library and went for it. Any thoughts?<p>[1]: <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fowler%E2%80%93Noll%E2%80%93Vo_hash_function" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fowler%E2%80%93Noll%E2%80%93...</a>

Oh this topic can cost you some years of your life

if only browsers respected this. none of browsers use ETag and If-None-Match mechanism. instead they do their own wizzardy caching...