Allow strong ETags

[pillarjs]

Allow strong ETags

[dougwilson]

I'm sorry, but strong ETags do not fit in the model of this library. A strong ETag must guarantee octet-by-octet identicalness (especially since we support Range requests). We are also stateless (helps keep memory down, especially when used in cluster) and streamy. To do strong ETags, you would have to hash the file contents, which means reading the whole file twice for every request: 1 to calculate the hash in a streamy fashion, 2 to send the new contents when the Etags do not match.

:(

[dougwilson]

Oh, and I forgot to say the reason we have to read the file twice is because we have to know the ETag before we know if were going to send the file, thanks to conditional requests (which are the whole point of ETags). We cannot just buffer the contents, ether, because then the server would fall over trying to serve large files (like videos).

[EvanHahn]

I agree with all this! Good call.

[marco2216]

What if you never modify the file during the server lifetime? If we make that assumption, could we perhaps calculate a strong ETag for all the files of the directory on startup?

[dougwilson]

Hi @marco2216 you certainly can do that! Then you can add a headers event listener on your send and look up that pre-calculated ETag and set it as the ETag header and send will use that instead of calculating one. You can then either leave etag: true if you want fallback for when you didn't set the ETag header, or etag: false for no fallback.

[marco2216]

Oh right, that's pretty much what I'm doing with serve-static. I was thinking if it should be a built in option in that library - I spent a good amount of time debugging why our static files changed ETag in-between deploys even though the file was identical. But that may also just be because of my inexperience with nginx etc., I read some of your answers in other threads that it's consistent with those servers to return a value based on the file-created-time and file length.
Or maybe, if you think that's outside the scope of serve-static, it might make sense to add a line to the readme explaining what the etag is based upon by default - I wouldn't mind doing that.