Какова цель (Apache) помещения inode в ETag?
В Интернете есть множество статей, в которых подробно объясняется, почему вы не хотите использовать стандартный формат Apode inode-mtime-size для ETag.
Но мне еще предстоит прочитать что-нибудь о том, что могло послужить причиной включения inode для Apache. На первый взгляд, это кажется полезным, только если нужно уметь различать факсимиле "октет для октета" одного и того же ресурса, но это, безусловно, противоречит самой цели ETags.
Авторы Apache не известны своей небрежной подачей интернет-стандартов, поэтому я чувствую, что что-то упустил. Кто-нибудь может уточнить?
РЕДАКТИРОВАТЬ: я спрашиваю это здесь, а не на ServerFault.com, потому что я использую веб-сервер, а не администрирую его. Чтобы узнать больше о том, почему это плохая идея, смотрите, например, здесь или здесь. Все такие статьи рекомендуют одно и то же: удаляйте иноды из ваших etags. Вопрос в том, есть ли какое-то преимущество для них?
1 ответ
Кажется, что такое можно легко сделать, ошибочно угадав, что является частым случаем, или предпочитая правильность, а не производительность, по умолчанию, когда возникает сомнение.
Позвольте мне написать историю о том, как это могло произойти:
Они рано решают, что хеш / контрольная сумма в содержимом является плохой идеей по соображениям производительности. "Кто знает, насколько большим может быть файл? Мы не можем пересчитать его все время..." Поэтому они решают, что размер и дата приблизят вас.
"Но подождите, - говорит человек А., - ничто не гарантирует, что у вас нет коллизии размера файла. На самом деле, есть случаи, например, двоичные файлы прошивки, когда размер файла всегда одинаков, и вполне возможно, что несколько загружен с компьютера разработчика в одно и то же время, поэтому этого недостаточно, чтобы различать различное содержимое ".
Человек Б: "Хм, хорошая мысль. Нам нужно что-то, что неразрывно связано с содержимым файла. Что-то, что в сочетании с измененным временем наверняка может сказать вам, является ли это тем же содержимым".
Человек А: "А как насчет inode? Теперь, даже если они переименуют файлы (например, они меняют" рекомендованный "на другой файл), etag по умолчанию будет работать нормально!"
Человек Б: "Я не знаю, инод кажется немного опасным".
Человек А: "Ну, что будет лучше?"
Человек Б: "Да, хороший вопрос. Я думаю, я не могу думать, что конкретно с ним не так, у меня просто общее плохое предчувствие".
Человек А: "Но, по крайней мере, это гарантирует, что вы загрузите новую, если она будет изменена. Худшее, что происходит, это то, что вы скачиваете чаще, чем нужно, и любой, кто знает, что им не нужно об этом беспокоиться, может просто повернуть". это от."
Человек Б: "Да, это имеет смысл. Это, вероятно, хорошо для большинства случаев, и это кажется лучше, чем легкие альтернативы".
Отказ от ответственности: у меня нет никаких внутренних знаний о том, о чем могли думать разработчики Apache. Это всего лишь догадки и попытки придумать правдоподобную историю. Но я, конечно, видел, что подобные вещи случаются достаточно часто.
Вы никогда не знаете, о чем вы не думали (в этом случае избыточные серверы с балансировкой нагрузки, обслуживающие одни и те же файлы, были более типичными, чем беспокоиться о коллизиях размер + время). Балансировщик нагрузки не является частью Apache, что облегчает такой контроль.
Кроме того, режим сбоя здесь заключается в том, что вы не очень эффективно использовали кеш (НЕ из-за неправильных данных), что, возможно, лучше, хотя и раздражает. Это говорит о том, что даже если бы они об этом подумали, они могли бы разумно предположить, что кто-то с достаточным интересом настроит балансировщик нагрузки, также подойдет для настройки деталей своей конфигурации.
PS: дело не в стандартах. Ничто не определяет, как вы должны рассчитывать etag, просто этого должно быть достаточно, чтобы определить, изменилось ли содержимое с высокой вероятностью.