strong etag support? about send HOT 4 CLOSED

We are also affected by this. It caught us by surprise.

from send.

+1 for (2)

from send.

I would prefer this module does not diverge from the methodology that Apache, NGINX, etc. use for interoperability. Especially because Node.js should always be the last resort to use to server static files from the file system do the Node.js not having async file IO, and thus your thread pool will be full of file requests.

Is the same issue present when using other file serving methods like NGINX? Does npm believe this is a bug or a functions as designed?

Note that this module allows you to calculate etags in anyway you want, so just because it works like A by default does not mean you cannot make it calculate like B if that us your desire.

from send.

I'm going to close this issue as stale, mainly because I never got a response to my question.

I looked it up and Apache / NGINX would have the same "problem" -- they both calculate ETags by default the same way as this module: the mtime + size. But just like Apache / NGINX, you can change the ETags in this module if you want to use a different method. For example, you could include the inode of the file, though be aware that if you use multiple servers, the ETags will differ between servers when that is done, which may cause other issues.

I'll suggest that if you are serving files that are unpacked from these npm tarballs, to do one of the above methods, or if anyone knows how to actually calculate a strong ETag without reading the entire file from disk multiple times or holding the entire file in memory, you're welcome to make a pull request to implement strong ETags.

from send.