Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New ETag generation method #29

Closed
kanongil opened this issue Jul 8, 2015 · 2 comments
Closed

New ETag generation method #29

kanongil opened this issue Jul 8, 2015 · 2 comments
Assignees
Labels
Milestone

Comments

@kanongil
Copy link
Member

@kanongil kanongil commented Jul 8, 2015

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: modification time + file size, similar to nginx & express.js.

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 etagMethod option, to allow consistent tag values across servers for git deployed assets, etc.

Any input on this would be much appreciated.

@kanongil kanongil added the feature label Jul 8, 2015
@hueniverse

This comment has been minimized.

Copy link
Member

@hueniverse hueniverse commented Jul 8, 2015

Distributed deployments are extremely common. I'm ok with offering options but not changing the default.

@kanongil

This comment has been minimized.

Copy link
Member Author

@kanongil kanongil commented Jul 8, 2015

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.

kanongil added a commit to kanongil/inert that referenced this issue Jul 13, 2015
kanongil added a commit to kanongil/inert that referenced this issue Jul 13, 2015
@kanongil kanongil closed this in 2937c90 Oct 18, 2015
@kanongil kanongil added this to the 3.2.0 milestone Oct 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.