CODEWITHSUNDEEP
httpcachinghashstandardsetag
awakecoding
awakecoding

Reputation: 428

Is there a standard for HTTP non-opaque, hash-based ETag headers?

Long story short, I would like to explicitly indicate a given hash algorithm (SHA256) that was used to compute the HTTP ETag header of a resource. The way I understand it, the ETag header value is opaque by design, but in practice it is common to compute it using a hashing function.

I understand the idea of keeping the ETag value opaque, which I guess it there to prevent unintended optimizations by caching proxies that would try to interpret its value and do something other than compare the current ETag with the cached ETag. However, I was wondering if someone wrote an RFC defining usage of an additional HTTP header that would explicitly indicate a hashing algorithm used to compute the corresponding ETag value, therefore making it non-opaque, while remaining compatible with caching proxies that rely only on the opaque ETag value.

In my case, I am not using a caching proxy: I have a native application that should fetch multiple resources from own HTTP microservice, which means I control both the HTTP client and server implementations. Some of these resources are meant to be stored on disk, and as an optimization I would like to simply load the current file, compute it's SHA256 sum, and use it as the ETag of the last cached resource when fetching the same resource again from my microservice.

In other words: I make GET requests on a specific resource that does not change often, but I still need to check at regular intervals. Instead of transmitting the resource over the network every time, I would like to compute the SHA256 sum of the file and use it as ETag, allowing me to avoid saving the opaque ETag alongside the file. Since I control the microservice serving the resource, I could easily use SHA256 sums as the ETag, and add a custom header to indicate that SHA256 was used to compute the ETAg. This ETag can remain opaque to clients not checking for the custom header, but those that can will treat it as a SHA256 sum.

Are there known implementations of something like this? I'm fine with using an obscure RFC that is not widely recognized, or some REST API documentation, but I'd rather look for existing designs I could implement before making my own. If I missed the widely recognized standard, it would be more than I wish for :)

Upvotes: 1

Views: 636

Answers (1)

Raedwald
Raedwald

Reputation: 48692

The semantics of a REST service is not given by any standard or RFC. Only you can specify the semantics of your REST service. This specification adds constrains or interpretations on top of the basic constraints of HTTP (etc.). If you want to specify that the ETag returned by your service is the SHA256 checksum of the representation, you can. Nothing more is needed. You don't need a special extra header or need to conform to some externally produced standard.

Upvotes: 2

Related Questions