Какова цель (apache) вкладывать iNode в ETAG?

Question

В Интернете много статей, подробно описывающих, почему вы могли бы нет Хотите использовать формат inode-mtime по умолчанию Apache для ETAGS.

Но я еще не прочитал что -либо о том, что могло бы мотивировать включение INODE для Apache в первую очередь. На первый взгляд, это кажется полезным только в том случае, если нужно иметь возможность дифференцироваться между факсимилями с октябным октом с одним и тем же ресурсом, но это, безусловно, противоречит самой цели ETAGS.

Авторы Apache не известны своими неаккуратными руками интернет -стандартов, поэтому я чувствую, что мне что -то упускаю. Кто -нибудь может уточнить?

РЕДАКТИРОВАТЬ: Я спрашиваю об этом здесь, а не на Serverfault.com, потому что я внедряю веб -сервер, а не администрирую его. Чтобы узнать больше о том, почему это плохая идея, см. EG здесь или же здесь. Анкет Все такие статьи рекомендуют одно и то же: удалите Inodes из ваших ETAG. Вопрос в том, есть ли какое -либо преимущество для них?

Answer 1

Похоже, что можно легко сделать с помощью неправильного предположения о том, что такое общий случай, или предпочитая правильность по умолчанию, когда бывает сомнение.

Позвольте мне составить историю о том, как это могло бы уйти:

Рано они решают, что хэш/контрольная сумма на содержимое - плохая идея по соображениям производительности. «Кто знает, насколько большим может быть файл? Мы не можем все время пересматривать их ...», чтобы они решали размер и дата приближают вас.

«Но подождите, - говорит человек А, - ничто не гарантирует, что у вас нет столкновения размера файла. Фактически, есть случаи, такие как двоичные файлы прошивки, когда размер файла всегда одинаковы, и вполне возможно, что некоторые из них Загружено с Dev Machine одновременно, поэтому этого недостаточно, чтобы различать различное содержание ».

Человек Б: «Хм, хороший момент. Нам нужно что -то, что по сути связано с содержимым файла. Что -то, что в сочетании с измененным временем может сказать вам наверняка, является ли это одинаковым содержимым».

Человек А: «А как насчет Инода?

Человек Б: «Я не знаю, Инод кажется немного опасным».

Человек А: "Ну, что будет лучше?"

Человек Б: «Да, хороший вопрос. Думаю, я не могу думать, что конкретно не так, у меня просто плохое чувство об этом».

Человек A: «Но, по крайней мере, это гарантирует, что вы скачиваете новый, если он изменится. Худшее, что случается, это то, что вы скачиваете чаще, чем нужно, и любой, кто знает, что им не нужно беспокоиться об этом, может просто повернуть это от."

Человек Б: «Да, это имеет смысл. Вероятно, это хорошо для большинства случаев, и это кажется лучше, чем легкие альтернативы».

Отказ от ответственности: у меня нет никаких внутренних знаний о том, о чем могли бы думать реализаторы Apache. Это все, что просто угадает ручной угадывание, и пытается составить правдоподобную историю. Но я, конечно, видел, как такие вещи случаются достаточно часто.

Вы никогда не знаете, о чем вы не думали (в данном случае, что избыточные сбалансированные серверы, обслуживающие одни и те же файлы, было более типичным, чем беспокоиться о столкновениях размера+времени). Балансировщик нагрузки не является частью Apache, что облегчает такой контроль.

Кроме того, режим сбоя здесь заключается в том, что вы не использовали совершенно эффективное использование кэша (не то, чтобы у вас были неправильные данные), что, возможно, лучше, хотя и раздражает. Что говорит о том, что даже если бы они подумали об этом, они могли бы разумно предположить, что кто -то с достаточным интересом для настройки балансировщика нагрузки также будет в порядке с настройкой деталей их конфигурации.

PS: Дело не в стандартах. Ничто не указывает, как вы должны рассчитать ETAG, просто того, что должно быть достаточно, чтобы сказать, изменилось ли содержимое с высокой вероятностью.