mod_gzip - обслуживание сжатого контента веб-сервером Apache - Страница 8

Автор: Майкл Шрёпл

Этот документ описывает некоторые возможные функциональные улучшения, которые, надеюсь, могут быть реализованы в текущей версии 1.3.26.1a mod_gzip без особых усилий и улучшить удобство использования этого модуля.

Класс журналирования и значение решающего правила фильтра

Решение о том, подходит ли содержимое документа для сжатия с помощью mod_gzip, в конечном итоге принимается во время оценки правил фильтра, определенных директивами mod_gzip_item_include и mod_gzip_item_exclude, которые проверяются функцией mod_gzip_validate1.

Но эта функция вызывается не менее чем в пяти местах в исходном коде, каждый раз с разными параметрами для конкретных частей классов правил, которые должны быть проверены в данный момент. В некоторых из этих случаев из ограниченной настройки параметров ясно, какой класс правила должен был привести к конкретному результату (но не какое значение правила!), в других случаях (таких как одновременная проверка всех правил классов file, uri, mime и handler) даже класс решающего правила неясен (потому что mod_gzip_validate1 возвращает такой неопределенный результат, что вызывающий не может даже понять, что именно произошло - в некоторых случаях даже внутренние ошибки кодируются как решение из-за правила исключения). В этих случаях даже разумная оценка кода состояния mod_gzip невозможна.

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

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

Конфигурируемый уровень сжатия gzip

В настоящее время mod_gzip использует уровень сжатия gzip 6. Это жестко закодировано присвоением gz1->level = 6 внутри функции gz1_init.

Чем выше уровень сжатия (gzip позволяет значения от 1 до 9), тем лучше эффект сжатия, но тем выше и потребление ЦП. Изменяя этот уровень сжатия, пользователь мог бы решить компромисс между нагрузкой на ЦП и экономией полосы пропускания в соответствии со своими требованиями. Собственные эксперименты показали, что уровень 3 уже приближает вас к эффекту уровня сжатия 6 - по крайней мере, выбор между этими двумя значениями должен быть оставлен пользователю.

Таким образом, было бы разумно сделать этот уровень сжатия настраиваемым, предложив другую директиву mod_gzip_compression_level.

Более пристальный взгляд Кристиана Крузе привел к выводу, что код сжатия Кевина Кайли для mod_gzip, похоже, не поддерживает все 9 уровней сжатия для

gzip

но в основном только те, которые необходимы для уровня 6 (хотя структура программы была разработана для реализации всех 9 уровней позже). Поэтому простая замена вышеупомянутой константы не достаточно; на самом деле, mod_gzip даже больше не может использоваться после такого рода модификации.

Булевы выражения в директивах include / exclude

mod_gzip 1.3.19.1a использует - вызванное его способом встраивания внутри обработки запросов Apache - сложную, двухуровневую процедуру фильтрации, чтобы решить, следует ли сжимать результат запроса. (В модифицированной архитектуре Apache 2.0 может быть возможен более простой способ встраивания.)

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

Тем не менее, все правила независимы друг от друга; текущие доступные директивы не позволяют пользователю выразить, что определенные MIME-типы должны передаваться только в сжатом виде для определенных браузеров - связь AND между несколькими правилами отсутствует.

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

Обслуживание идентичных HTTP заголовков для запросов GET и HEAD

Согласно RFC 2616, для запроса, использующего метод HEAD, реализация, соответствующая HTTP/1.1, должна обслуживать HTTP заголовки, идентичные тем, которые были бы обслужены для запроса того же ресурса с использованием метода GET.

В случае mod_gzip это означало бы, что даже для запроса HEAD содержимое должно быть сжато (или прочитано, в случае статически предсжатого файла), просто чтобы иметь возможность сгенерировать правильный заголовок Content-Length HTTP.

На данный момент mod_gzip не обрабатывает этот (крайне редкий) случай применения (вероятно, из-за соображений производительности); тем не менее, согласно RFC 2119 это может привести к тому, что поведение модуля будет лишь условно совместимо с HTTP/1.1, поскольку должна быть действительная причина для несоответствия рекомендуемому требованию.

Оригинальное местоположение этого документа:

http://www.schroepl.net/projekte/mod_gzip/enhancements.htm