ETags are wrong when serving files from the Nix store with nginx

[emilazy]

Describe the bug
#48337 doesn't seem to have properly fixed the bug; the ETag appears to be shared between all files of the same derivation.

To reproduce

emily@renko ~> curl -sI https://mew.build/ | grep etag
etag: "iqhlq2b7rmki16cgyf1ll2wiimb6fk6x"
emily@renko ~> curl -sI https://mew.build/notes.html | grep etag
etag: "iqhlq2b7rmki16cgyf1ll2wiimb6fk6x"

Expected behaviour
Distinct ETags for distinct paths.

[emilazy]

@yegortimoshenko I can't figure out why this would be happening from looking at the #48337 code; could you take a look at this? Happy to provide whatever debugging context is needed.

[lukateras]

ETags are compared per-resource, at least as far as I understand RFC 7232, which speaks in terms of target resources:

Conditional request preconditions are based on the state of the
target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that
set). [...]

In which case, if true, it shouldn't matter if all resources share the same ETag. By the way, iqhlq2b7rmki16cgyf1ll2wiimb6fk6x is the corresponding Nix store hash. Do you run into any issues with the current behavior?

[emilazy]

That makes sense, on second thought, given that it's usually derived from the mtime... I can imagine clients being broken enough to globally cache based on it, but I haven't experienced it yet in practice.

My preferred approach would be to just hash the entire Nix store path, which would ensure a more unique ETag without meaningful overhead, but the current approach is probably fine.