Реализация HTTP ETags на веб-сервере

Question

В настоящее время я изучаю возможность внедрения ETags на веб-сервере для поддержки только условного GET. Веб-сервер написан на C++ и работает только в ОС Windows. После некоторых исследований у меня есть несколько вопросов ... У серверов, которые реализуют эту функцию, обычно кэшируются ETag GUID для определенного файла? Я не очень хорошо знаком с базой кода Apache, но мне удалось найти функцию ap_condition_if_none_match, но мне не совсем понятно, как они проверяют значение GUID для заголовка if-none-match. Если они кэшируют вещи, и файл должен был измениться за пределами сервера, делающего что-либо (т. Е. Пользователь обновил его), как сервер знает, что файл в его кеше уже недействителен? Возможно, они используют какой-либо API для «просмотра» изменений каталога?

Edit: я рассматриваю кое-какую информацию я нашел здесь: https://httpd.apache.org/docs/2.4/caching.html

Answer 1

В Apache, то ETag производится из файла индексных дескрипторов, размер и последнего изменения времени: http://httpd.apache.org/docs/2.2/mod/core.html#FileETag

Есть разные варианты, вы можете настроить их. Я дам вам список возможных вариантов, от минимального до наиболее надежного:

1. [FASTEST OPTION] Проверьте последнее время изменения файла с более высокой частотой, чем 1 секунда. Например, в Windows время файла измеряется в 100-наносекундных интервалах. Также проверьте размер файла и inode, как это делает Apache. В Windows вместо inode вы можете запросить идентификатор файла открытого дескриптора через GetFileInformationByHandle. См. NFileIndexHigh, nFileIndexLow; это высокая и низкая части соответственно идентификатора файла, который составляет 64 бита. Если время, размер и индекс файла изменились, пересчитайте хеш.
2. [SAFER OPTION] Помимо файла времени, размера и inode, также проверяйте содержимое файла с помощью очень быстрой функции CRC32, реализованной Intel (SSE4.2), - это намного быстрее, чем любая реализация CRC32 существовала до SSE4.2. Если время файла или CRC32 изменилось, пересчитайте хэш.
3. [БЫСТРЫЙ И БЕЗОПАСНЫЙ ВАРИАНТ, НО ПОТРЕБИТ ПОЛЬЗОВАТЕЛЯ] Только вычислять хэши во время работы вашего сервера. Когда ваш сервер сначала запускается, он не должен вычислять хеширование. Если файл сначала запрашивается, вычислите хэш и сохраните его до выхода сервера. Пока сервер работает, отслеживайте изменения файлов (файлов, для которых у вас есть хэши), используя уведомления об изменениях в файлах операционной системы. Например, в Widnows есть FindFirstChangeNotification.

Для хэш-значения самого ETag я бы рекомендовал криптографическую хеш-функцию, даже более сильную для цифровых подписей. Я бы не рекомендовал хеш-функцию, явно не предназначенную для криптографически сильной, так как они не производят такой маленький дайджест, как криптохэши для сопоставимого уровня сопротивления столкновениям. При столкновении я имею в виду, что два разных файла производят один и тот же хэш. MD5 по-прежнему очень хорош для мониторинга изменений содержимого файла - с учетом его большого объема и малого размера дайджеста. Это самая быстрая функция хэш-функции. Вы также можете найти быструю реализацию MD5 в сборке, например, от OpenSSL или от https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly или http://blog.bfitz.us/?p=827