为什么Nginx etag值由last-modified-time和content-length生成？

Question

Nginx etag source

etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
                              r->headers_out.last_modified_time,
                              r->headers_out.content_length_n)
                  - etag->value.data;

r->headers_out.etag = etag;

如果服务器中的文件last-modified-time已更改但文件内容尚未更新，那么etag值是否相同？

为什么不通过内容哈希生成etag值？

Answer 1

为什么不通过内容哈希生成etag值？

除非nginx记录了原因，否则无法说出原因。

我猜测他们是这样做的，因为它非常快，只需要一段时间。计算散列可能是一项代价高昂的操作，需要的时间取决于响应的大小。 nginx以其简单和速度而着称，可能不会过多地增加这种开销。

如果服务器中的文件last-modified-time已更改但文件内容尚未更新，则etag值是否相同？

不，它不会相同，因此必须重新提供文件。结果是响应速度比基于散列的ETag慢，但响应是正确的。

该算法的更大问题是内容可能会在ETag保持不变的情况下发生变化，在这种情况下，响应将是不正确的。如果文件更改（以保持相同长度的方式）比Last-Modified标头的精度更快，则可能发生这种情况。 （当然，不同的内容也可能产生相同的哈希值，因此这种方式也不能完全免受问题的影响。）

因此，大概是nginx权衡了这种权衡 - 一个更快的响应，但是有一个很小的机会是错误的 - 并且认为这是值得的。