Что цель (Apache) помещает inode в Завершающий тег?

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

Позвольте мне составить историю о том, как это могло происходить:

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

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

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

Человек A:" А как насчет inode? Теперь, даже если они переименуют файлы (например, они изменят «рекомендуемый» на другой файл), etag по умолчанию будет работать нормально! »

Человек B:« Не знаю, индексный дескриптор кажется немного опасным »

Человек A: «Что бы было лучше?»

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

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

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

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

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

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

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

они могли разумно предположить, что кто-то, кто достаточно заинтересован в настройке балансировщика нагрузки, также согласен с настройкой деталей своей конфигурации.

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

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

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