Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Currently ETags are calculated based on the SHA1 hash of the file. This requires a file to be completely read before its tag can be calculated and put into the header of a request. To circumvent this, inert currently omits the ETag header until a complete file has been served to a client, caching the value for future requests.
The file hashing causes undue complexity for limited gains, and I would like to replace this with a value computed from:
As far as I can tell, this updated method should mainly affect cases where the same file is stored on multiple servers, served by different hapi instances behind a load balancer. Currently they are always served with the same ETag, but will require synchronization of the modification dates to achieve the same result with the new method.
I'm considering to completely replace the generation method but am also considering adding it as a new
Any input on this would be much appreciated.
I thought that might be the case, though it should only be a problem for distributed deployments that don't control the modification time of the deployed static assets (like git). I am still vary on keeping it, as is, since it can cause inconsistent behavior as seen in hapijs/hapi#2628
Actually, I think a better solution might be to update the current hashing logic to always add an ETag to responses at the expense of latency on uncached requests, while keeping this "new" method as an option for cases where you need the extra performance and hopefully understand its limits.