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