Implement ETag-based caching about huxley2 HOT 6 CLOSED

This is available in the latest release, ignoring the generated at timestamp when hashing.

from huxley2.

Thank you so much! :)

from huxley2.

Huxley is just a proxy and considered feature-complete. It doesn't hold state and doesn't know if data is stale or not. You would probably need to build something on top of the push port to implement this feature.

from huxley2.

There's no need to know if data is stale or not. The response just needs to be hashed before it is sent, and if the hash is the same as supplied in the ETag request header, Huxley can respond with a 304 code.

The objective isn't to prevent unnecessary API calls from the server to NRE, but to prevent unnecessary data transfer when no data has changed so the browser can use its own cached ETagged copy.

from huxley2.

Thanks for clarifying. Looks like Mads has a gist for some ETag middleware so I might see if that still works.

from huxley2.

I've added this but it's not quite that simple. NRE add a millisecond precision "generated at" timestamp to every response so the hash will always be different and so not useful as an ETag.

from huxley2.