Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ETag and HTTP Caching

rednafi.com

Post reply on HN
Print view View original

1–10 of 92 posts

Re: ETag and HTTP Caching

#2

Post by JaggedJax »

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.

It seems like generating a weak ETag would take more effort since you'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.

Re: ETag and HTTP Caching

#6

Post by akira2501 »

The ETag can be _anything_. I have an API that serves "files" 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:

    ETag: W/"750"
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's a great standard.

Re: ETag and HTTP Caching

#7

Post by clessg »

JaggedJax wrote: post #2

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. It seems like generating a weak ETag would take more effort since you'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.

That's because it isn't really generating a weak ETag. From the article:

> You could make the `calculateETag` function format-agnostic, so the hash stays the same if the JSON format changes but the content does not. The current `calculateETag` implementation is susceptible to format changes, and I kept it that way to keep the code shorter.

They seem to agree, a true weak ETag implementation would probably be trickier and require more code :P I'd be fascinated to see how that might work in practice, though.

Re: ETag and HTTP Caching

#9

Post by kevincox »

akira2501 wrote: post #6

The ETag can be _anything_. I have an API that serves "files" 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: ETag: W/"750" This also means the API can just check the revision number and avoid pulling out and decompressing some of the larger payloads that are st…

Can't it be a strong validator if the files don't change at all between revisions? Or does the revision number only increment on "significant" revisions?

Re: ETag and HTTP Caching

#10

Post by akira2501 »

kevincox wrote: post #9
akira2501 wrote: post #6

The ETag can be _anything_. I have an API that serves "files" 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: ETag: W/"750" This also means the API can just check the revision number and avoid pulling out and decompressing some of the larger payloads that are st…

Can't it be a strong validator if the files don't change at all between revisions? Or does the revision number only increment on "significant" revisions?

The data does not but certain metadata elements might. It probably could be a strong validator anyways for it's use cases, but I made the decision in a hurry.
Post reply on HN