Почему не значение etag, сгенерированное хэшем содержимого?
Если nginx не задокументировал причину, невозможно сказать почему .
Мои предположения заключается в том, что они сделали это таким образом, потому что это очень быстро и занимает только постоянное количество времени. Вычисление хэша может быть дорогостоящей операцией, а количество времени, необходимое в зависимости от размера ответа. nginx, имеющий репутацию простоты и скорости, возможно, не пожелал добавить эти накладные расходы.
Если время последнего изменения файла на сервере изменилось, но содержимое файла не было обновлено, будет ли значение etag таким же?
Нет, это не будет тем же самым, и поэтому файл должен быть повторно предоставлен. В результате отклик будет медленнее, чем при использовании ETag
на основе хеша, но ответ будет правильным.
Большая проблема с этим алгоритмом заключается в том, что содержимое может измениться, в то время как ETag
остается прежним, и в этом случае ответ будет неправильным. Это может произойти, если файл изменяется (таким образом, что его длина сохраняется) быстрее, чем точность заголовка Last-Modified
. (Разумеется, разный контент также может создавать один и тот же хеш, так что этот способ также не полностью защищен от проблем.)
Итак, предположительно, nginx взвесил этот компромисс - более быстрый ответ, но с небольшим шансом ошибочности - и решил, что оно того стоило.