Почему значение Etag Nginx создается последним измененным временем и длиной содержимого? - PullRequest
0 голосов
/ 26 апреля 2019

Источник Nginx etag

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, сгенерированное хэшем содержимого ?

1 Ответ

1 голос
/ 26 апреля 2019

Почему не значение etag, сгенерированное хэшем содержимого?

Если nginx не задокументировал причину, невозможно сказать почему .

Мои предположения заключается в том, что они сделали это таким образом, потому что это очень быстро и занимает только постоянное количество времени. Вычисление хэша может быть дорогостоящей операцией, а количество времени, необходимое в зависимости от размера ответа. nginx, имеющий репутацию простоты и скорости, возможно, не пожелал добавить эти накладные расходы.

Если время последнего изменения файла на сервере изменилось, но содержимое файла не было обновлено, будет ли значение etag таким же?

Нет, это не будет тем же самым, и поэтому файл должен быть повторно предоставлен. В результате отклик будет медленнее, чем при использовании ETag на основе хеша, но ответ будет правильным.

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

Итак, предположительно, nginx взвесил этот компромисс - более быстрый ответ, но с небольшим шансом ошибочности - и решил, что оно того стоило.

...