ETag should be a hash

[Joannis]

Describe the bug

Currently, ETag for file serving is generated from the modified date and file size. A hash is a stronger alternative, and can be precomputed if available. See #2943.

[jhoughjr]

"ETag should be a hash of the contents (not just (lastModificationTime)-(fileLength))" re precomputing, precomputing when?

[jhoughjr]

if the hash is to be based on the file contents, what algorithm should be used?

[jhoughjr]

currently im testing an md5 hash on the contents.

[jhoughjr]

I dont think this is teastable.

[Joannis]

I think that's mostly up for debate / deferred to the end user implementation. Many people prefer not using MD5, but rather SHA1, or a modern standard like SHA2 (whichever variant). And since hashes vary depending on the user and their infrastructure, I'd say cached hashes should not be mandated to use a specific algorithm.

I think it would be nice to support non-cached hashing out of the box, however that might be a two-step process. I'd love us to have an algorithm option in the case of non-cached hashes such as etag: .md5 or etag: .sha1

[jhoughjr]

can do that tonight I think.

[linus-hologram]

I am going to give this a try as my first vapor contribution :)

[linus-hologram]

As discussed on discord, I'll try to compute a hash whenever data is written to the file system and store it in a file attribute. As for the hashing technique, SHA-1, SHA-256 or similar will be used.

[linus-hologram]

We're using a different approach now. Creating the hash solely when a file is written to the file system using Vapor turned out to be unviable since that would not create any file hashes for manually added files.

Instead, the hash is now generated whenever a file is streamed back to the client, provided the hash is not already cached.

[linus-hologram]

@0xTim will the PR #3015 be merged some time soon?

[linus-hologram]

@0xTim any update on this?