mod_wsgi#

Описание#

mod_wsgi предназначен для обеспечения WSGI-совместимого интерфейса, который позволяет запускать Python-приложения на веб-сервере Apache HTTP Server. Модуль выступает посредником между веб-сервером и Python-приложениями, реализуя спецификацию WSGI (Web Server Gateway Interface). WSGI - это стандарт взаимодействия между Python-программой, выполняющейся на стороне сервера, и самим веб-сервером, который позволяет серверу передавать HTTP-запросы приложению и получать от него ответы.

mod_wsgi поддерживает режимы работы:

Встраиваемый режим (embedded mode) - Python-приложение выполняется внутри процессов Apache HTTP Server. Это удобно для небольших проектов, но может быть менее эффективным для крупных приложений из-за высокой нагрузки на память.
Режим демона (daemon mode) - приложение запускается в отдельных процессах, управляемых mod_wsgi. Этот режим рекомендуется для более сложных и ресурсоемких приложений.

В поставке ОС SberLinux OS Server содержатся следующие варианты пакетов, с помощью которых можно установить модуль mod_wsgi:

python3-mod_wsgi... - для установки версии модуля, совместимой с Python 3.9;
python3.11-mod_wsgi... - для установки версии, совместимой с Python 3.11.

Чтобы проверить доступные версии пакетов, выполните:

dnf provides */mod_wsgi

Далее установите тот пакет, который соответствует используемой версии Python. Например, для Python 3.11 выполните:

dnf install python3.11-mod_wsgi

Примечание

Для корректной работы mod_wsgi необходимы:

Python версий 2.6 и 3.3 и выше, а также его общие библиотеки.
Соответствие веб-приложений Python спецификации WSGI (PEP 3333).
(опционально) модули:
- mod_ssl - для работы с HTTPS;
- mod_rewrite - для настройки правил перенаправления.

Пример конфигурации#

Пример конфигурации, настроенной с помощью модуля mod_wsgi:

<VirtualHost *:80>
    # Имя сервера (домен)
    ServerName example.com

    # Указание пути к WSGI-скрипту приложения
    WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

    # Настройка процесса демона (рекомендуется для сложных приложений)
    WSGIDaemonProcess myapp python-path=<path_to_myapp>
    WSGIProcessGroup myapp

    # Доступ к статическим файлам (например, CSS, JavaScript)
    Alias /static/ <path_to_myapp>/static/
    <Directory <path_to_myapp>/static>
        Require all granted
    </Directory>

    # Разрешение доступа к директории с WSGI-скриптом
    <Directory <path_to_myapp>>
        <Files myapp.wsgi>
            Require all granted
        </Files>
    </Directory>
</VirtualHost>

Директивы#

Список директив модуля представлен в таблице ниже.

Директивы `mod_wsgi`#
Синтаксис	Значение по умолчанию	Контекст	Описание
`WSGIAcceptMutex Default \| <method>`	`WSGIAcceptMutex Default`	`server config`	Указывает тип мьютекса принятия, используемого процессами-демонами - метод, который `mod_wsgi` будет использовать для сериализации нескольких процессов-демонов в группе процессов, принимающих запросы на сокетное соединение от дочерних процессов веб-сервера. Если директива не определена, будет использоваться тот же тип механизма мьютекса, что и для основных дочерних процессов при принятии соединений от клиента. Если задано, типы методов совпадают с директивой `AcceptMutex`
`WSGIAccessScript <path> [<option>]`	Нет	`directory`, `.htaccess`	Указывает скрипт, реализующий контроль доступа для хоста. Опция `application-group=<name>`, которую можно передать директиве `WSGIAccessScript`, задает имя группы приложений в указанном процессе, для которой будет загружен файл скрипта. Если опция `application-group` не указана, будет использовано специальное значение `%{GLOBAL}` - файл скрипта будет загружен в контексте первого интерпретатора, созданного Python при инициализации. Обратите внимание, что скрипт всегда выполняется в процессах, связанных с встроенным режимом. Невозможно делегировать выполнение скрипта так, чтобы он выполнялся в контексте процесса-демона
`WSGIApplicationGroup <name> \| %{GLOBAL} \| %{SERVER} \| %{RESOURCE} \| %{ENV:variable}`	`WSGIApplicationGroup %{RESOURCE}`	`server config`, `virtual host`, `directory`	Указывает, к какой группе приложений принадлежит WSGI-приложение или набор приложений. Все WSGI-приложения в одной группе будут выполняться в контексте одного и того же подинтерпретатора Python-процесса, обрабатывающего запрос. Установка `WSGIApplicationGroup` не контролирует, какими процессами обрабатывается запрос; это делает директива `WSGIProcessGroup`. Аргументом к `WSGIApplicationGroup` может быть одна из четырех специальных переменных или явное имя. Специальные переменные: `%{GLOBAL}` — имя группы приложений будет установлено в пустую строку; `%{SERVER}` — имя группы приложений будет установлено на имя сервера; `%{RESOURCE}` — имя группы приложений будет установлено на имя сервера и порт, к которому добавляется значение переменной окружения `SCRIPT_NAME`; `%{ENV:variable}` — имя группы приложений будет установлено на значение указанной переменной окружения. Обратите внимание, что во встроенном режиме или в многопроцессной группе процессов-демонов будет существовать экземпляр названного подинтерпретатора в каждом процессе
`WSGIAuthGroupScript <path> [<option>]`	Нет	`directory`, `.htaccess`	Указывает скрипт, реализующий авторизацию групп с использованием директивы `Require`. Опция `application-group=<name>`, которую можно передать директиве, задает имя группы приложений в указанном процессе, для которой будет загружен файл скрипта. Если опция `application-group` не указана, будет использовано специальное значение `%{GLOBAL}` - файл скрипта будет загружен в контексте первого интерпретатора, созданного Python при инициализации. Обратите внимание, что скрипт всегда выполняется в процессах, связанных с встроенным режимом. Невозможно делегировать выполнение скрипта так, чтобы он выполнялся в контексте процесса-демона
`WSGIAuthUserScript <path> [<option>]`	Нет	`directory`, `.htaccess`	Указывает скрипт, реализующий провайдер аутентификации. Такой провайдер может использоваться в случае процесса аутентификации, связанного с HTTP Basic и Digest, при предоставлении только учетных данных пользователя для аутентификации. Другие модули веб-сервера, реализующие пользовательские механизмы аутентификации, также могут использовать этот провайдер аутентификации, если они используют соответствующий C API для доступа. Опция, которую можно передать директиве - `application-group=<name>` — задает имя группы приложений в указанном процессе, для которой будет загружен файл скрипта. Если опция `application-group` не указана, будет использовано специальное значение `%{GLOBAL}` - файл скрипта будет загружен в контексте первого интерпретатора, созданного Python при инициализации. Обратите внимание, что скрипт всегда выполняется в процессах, связанных с встроенным режимом. Невозможно делегировать выполнение скрипта так, чтобы он выполнялся в контексте процесса-демона
`WSGICallableObject <name> \| %{ENV:variable}`	`WSGICallableObject application`	`server config`, `virtual host`, `directory`, `.htaccess`	Переопределяет имя объекта Python, который используется в файле скрипта в качестве точки входа в WSGI-приложение. Когда используется `%{ENV}`, переменная окружения ищется через внутренние заметки веб-сервера и структуры данных окружения подпроцессов, а если не найдена, то через `getenv()` из процесса веб-сервера. В конфигурационном файле Apache HTTP Server переменные окружения, доступные с использованием ссылки `%{ENV}`, могут быть настроены с помощью директив, таких как `SetEnv` и `RewriteRule`. Обратите внимание, что имя вызываемого объекта должно быть объектом, присутствующим в глобальной области видимости в файле WSGI-скрипта. Невозможно использовать точечный путь для обращения к подобъекту модуля, импортированного в файл WSGI-скрипта
`WSGICaseSensitivity On\|Off`	`WSGICaseSensitivity Off`	`server config`	Определяет, является ли файловая система чувствительной к регистру. Это необходимо для корректной работы системы кеширования модулей, чтобы в памяти оставался только один модуль, когда пути с разным регистром используются для идентификации одного и того же файла скрипта. Директива `WSGICaseSensitivity` может быть использована для явного указания чувствительности к регистру конкретного WSGI-приложения, тем самым переопределяя значение по умолчанию для любой платформы. Значение `On` указывает, что файловая система чувствительна к регистру. Поскольку это устанавливается в основной конфигурации сервера, оно будет применяться ко всему сайту. Все пути должны находиться в файловой системе с одинаковым регистром
`WSGIChunkedRequest On\|Off`	`WSGIChunkedRequest Off`	`server config`, `virtual host`, `directory`, `.htaccess`	Включает/отключает поддержку содержимого запросов с использованием чанков. WSGI технически не может поддерживать содержимое запросов с чанками без предварительного чтения и буферизации всего контента. Это связано с тем, что WSGI требует, чтобы `CONTENT_LENGTH` был установлен, когда есть какой-либо контент запроса. В `mod_wsgi` буферизация не выполняется. Таким образом, чтобы иметь возможность читать контент запроса в случае кодирования передачи чанками, необходимо выйти за рамки спецификации WSGI. Первый вариант — вызвать `read()` на `wsgi.input`, но не передавать никаких аргументов. Это приведет к тому, что весь контент запроса будет прочитан и возвращен. Второй вариант — циклически вызывать `read()` на `wsgi.input` с установленным размером блока, переданным в качестве аргумента, и делать это до тех пор, пока `read()` не вернет пустую строку. Поскольку оба метода вызова не разрешены в соответствии со спецификацией WSGI, использование этих методов сделает код технически непереносимым для других механизмов хостинга WSGI, которые это не поддерживают. Некоторые WSGI-фреймворки включают поддержку обработки контента запросов с чанками, а также случаев, когда сжатый контент запроса расширяется веб-сервером, так что `CONTENT_LENGTH` более не является точным. Необходимое поведение включается в этих фреймворках, когда WSGI-сервер передает нестандартный ключ `wsgi.input_terminated`, установленный в `True`, в словаре окружения WSGI для каждого запроса. Когда это происходит, веб-фреймворки будут читать весь доступный ввод и игнорировать `CONTENT_LENGTH`. Поскольку `mod_wsgi` гарантирует, что пустая строка возвращается, когда весь ввод исчерпан, он всегда устанавливает этот флаг
`WSGIDaemonProcess <name> [<options>]`	Нет	`server config`, `virtual host`	Настраивает отдельные процессы-демоны для запуска приложений. С помощью директивы можно указать, что должны быть созданы отдельные процессы-демоны, которым можно делегировать выполнение WSGI-приложений. Если веб-сервер был запущен от имени пользователя `root`, процессы-демоны могут работать от имени пользователя, отличного от того, под которым обычно работают дочерние процессы. Когда включены и используются отдельные процессы-демоны, процесс выделяется `mod_wsgi`, и единственное, что делают процессы, — это запуск WSGI-приложений, назначенных этой группе процессов. Любые другие модули, такие как PHP, или действия, такие как обслуживание статических файлов, продолжают выполняться в стандартных дочерних процессах веб-сервера. Обратите внимание, что после указания на создание процессов-демонов с помощью директивы `WSGIDaemonProcess` необходимо также использовать директиву `WSGIProcessGroup` или опцию `process-group` в `WSGIScriptAlias`, чтобы делегировать конкретные WSGI-приложения для выполнения в этих процессах-демонах. Также обратите внимание, что имя группы процессов-демонов должно быть уникальным для всего сервера - невозможно использовать одно и то же имя группы процессов-демонов в разных виртуальных хостах. Возможные опции: - `processes=<num>` - количество процессов-демонов, которые должны быть запущены в этой группе; - `threads=<num>` - количество потоков, которые будут созданы для обработки запросов в каждом процессе-демоне в группе; - `display-name=<value>` - другое имя, которое будет отображаться для процесса-демона при использовании команды `ps` для составления списка процессов; - `home=<directory>` - абсолютный путь к каталогу, который должен использоваться в качестве начального текущего рабочего каталога процессов-демонов в группе; - `user=<name>\|#<uid>` - имя UNIX или числовой идентификатор пользователя, от имени которого должны запускаться процессы-демоны; - `group=<name>\|#<gid>` - имя UNIX или числовой идентификатор группы, от имени которой должны запускаться процессы-демоны; - `supplementary-groups=group1\|group1,group2` - список дополнительных UNIX-групп, к которым должен быть добавлен пользователь, от имени которого запускается группа процессов-демонов; - `umask=0<nnn>` - значение, которое будет использоваться для `umask` процессов-демонов в группе; - `lang=<locale>` - текущая языковая локаль, соответствующая переменной окружения `LANG`; - `locale=<locale>` - текущая языковая локаль, соответствующая переменной окружения `LC_ALL`; - `script-user=<name>\|#<uid>` - пользователь, который должен быть владельцем любого WSGI-скрипта, делегированного для выполнения в группе процессов-демонов; - `script-group=<name>\|#<gid>` - группа, которая должна быть группой любого WSGI-скрипта, делегированного для выполнения в группе процессов-демонов; - `python-home=<directory>` - местоположение виртуального окружения Python, которое будет использоваться процессами-демонами; - `python-path=<directory>\|<directory>:<directory>` - каталог или список каталогов, разделенных двоеточием, которые будут добавлены в путь поиска модулей Python, т.е. в `sys.path`; - `python-eggs=<directory>` - каталог, который будет использоваться в качестве каталога кеша Python egg; - `restart-interval=<seconds>` - временной лимит в секундах, в течение которого процесс-демон должен работать перед перезапуском; - `maximum-requests=<number>` - лимит на количество запросов, которые процесс-демон должен обработать перед тем, как он будет остановлен и перезапущен; - `inactivity-timeout=<seconds>` - максимальное количество секунд, которое может пройти, прежде чем процесс-демон будет остановлен и перезапущен, когда он вошел в неактивное состояние; - `request-timeout=<seconds>` - максимальное количество секунд, в течение которых запрос может выполняться, прежде чем процесс-демон будет перезапущен; - `deadlock-timeout=<seconds>` - максимальное количество секунд, которое может пройти, прежде чем процесс-демон будет остановлен и перезапущен после обнаружения потенциальной блокировки на Python GIL; - `startup-timeout=<seconds>` - максимальное количество секунд, которое может пройти в ожидании успешной загрузки файла WSGI-скрипта процессом-демоном; - `graceful-timeout=<seconds>` - процесс продолжит работать в течение указанного количества секунд, принимая новые запросы, чтобы увидеть, достигнет ли процесс неактивного состояния (когда используется `maximum-requests` и максимум достигнут, или используется `cpu-time-limit` и достигнут лимит CPU, или используется `restart-interval` и достигнут лимит времени); - `eviction-timeout=<seconds>` - тайм-аут, который контролирует, сколько секунд процесс будет ждать, принимая новые запросы, прежде чем достигнет неактивного состояния и завершится, когда процессу-демону отправляется сигнал плавного перезапуска (обычно `SIGUSR1`); - `shutdown-timeout=<seconds>` - максимальное количество секунд, которое может пройти в ожидании завершения работы процесса-демона, перед его принудительным завершением; - `connect-timeout=<seconds>` - максимальное время, в течение которого дочерний процесс веб-сервера будет ждать, пытаясь установить успешное соединение с процессами-демонами `mod_wsgi`; - `socket-timeout=<seconds>` - тайм-аут для отдельных операций чтения/записи на сокетном соединении между дочерними процессами веб-сервера и процессами-демонами `mod_wsgi`; - `queue-timeout=<seconds>` - тайм-аут ожидания, пока процесс-демон `mod_wsgi` примет запрос на обработку; - `listen-backlog=<number>` - лимит очереди прослушивания сокета процесса-демона; - `socket-user=<name>\|#<uid>` - владелец UNIX-сокета прослушивания для группы процессов-демонов; - `cpu-time-limit=<seconds>` - максимальное количество времени CPU, которое процесс-демон может использовать, прежде чем будет инициирован его перезапуск; - `cpu-priority=<num>` - приоритет планирования для процессов-демонов. Это может быть число в диапазоне от -20 до 20. Приоритет по умолчанию равен 0. Более низкий приоритет обеспечивает более благоприятное планирование; - `memory-limit=<num>` - максимальное количество памяти, которое может использовать процесс-демон; - `virtual-memory-limit=<num>` - максимальное количество виртуальной памяти, которое может использовать процесс-демон; - `stack-size=<bytes>` - количество виртуальной памяти в байтах, которое будет выделено для стека, соответствующего каждому потоку, создаваемому `mod_wsgi` в процессе-демоне; - `receive-buffer-size=<num>` - размер буфера UNIX-сокета для данных, получаемых процессом-демоном от дочернего процесса веб-сервера; - `send-buffer-size=<num>` - размер буфера UNIX-сокета для данных, отправляемых от процесса-демона обратно к дочернему процессу веб-сервера; - `header-buffer-size=<num>` - максимальный размер, который может иметь заголовок/значение ответа, возвращаемого из WSGI-приложения. По умолчанию составляет `32768` байт; - `response-buffer-size=<bytes>` - максимальное количество байт, которое будет буферизовано для ответа в дочерних процессах веб-сервера при проксировании тела ответа из WSGI-приложения. По умолчанию `65536` байт; - `response-socket-timeout=<num>` - максимальное количество секунд, которое может пройти до истечения времени ожидания операции обратной записи в HTTP-клиент, когда буфер ответа заполнен и данные принудительно сбрасываются
`WSGIDestroyInterpreter On\|Off`	`WSGIDestroyInterpreter On`	`server config`	Управляет тем, будет ли уничтожен интерпретатор Python при завершении или перезапуске процессов. Эта директива была добавлена из-за изменений в Python 3.9, где поведение очистки Python было изменено так, что он будет ожидать завершения демонов потоков. Это может привести к зависанию очистки интерпретатора Python в некоторых случаях, когда потоки создавались вне Python, как это происходит, когда Python встроен в C-программу, такую как `mod_wsgi`
`WSGIErrorOverride On\|Off`	`WSGIErrorOverride Off`	`server config`, `virtual host`, `directory`, `.htaccess`	Приводит к использованию документов об ошибках веб-сервера вместо тех, которые возвращаются WSGI-приложением, если WSGI-приложение работает в режиме демона. Это позволяет документам об ошибках соответствовать любому веб-сайту, с которым может быть интегрировано WSGI-приложение. Эта директива аналогична `ProxyErrorOverride`, но только для `mod_wsgi`. Директива не имеет эффекта, когда WSGI-приложение работает во встроенном режиме
`WSGIImportScript <path> [<options>]`	Нет	`server config`	Указывает файл скрипта, который будет загружен при запуске процесса. Для указания имени группы процессов и группы приложений, в которую будет загружен скрипт, необходимо задать опции: - `process-group=<name>` — указывает имя группы процессов, для которой будет загружен файл скрипта. Имя группы процессов может быть установлено в специальное значение `%{GLOBAL}`, что означает, что файл скрипта будет загружен для дочерних процессов веб-сервера. Любое другое значение указывает соответствующую группу процессов для режима демона `mod_wsgi`. - `application-group=<name>` — указывает имя группы приложений в процессе, для которой будет загружен файл скрипта. Имя группы приложений может быть установлено в специальное значение `%{GLOBAL}`, что означает, что файл скрипта будет загружен в контексте первого интерпретатора, созданного Python при инициализации. В противном случае он будет загружен в интерпретатор для указанной группы приложений. Поскольку файлы скриптов загружаются до начала приема любых запросов, задержка в загрузке скрипта не приведет к блокировке фактических запросов. Таким образом, директива `WSGIImportScript` может быть использована для предварительной загрузки файла скрипта WSGI-приложения при запуске процесса, чтобы он был готов, когда поступят фактические пользовательские запросы. Для случаев, когда несколько процессов обрабатывают запросы, это может уменьшить или устранить видимое зависание приложения при перезапуске веб-сервера или группы процессов в режиме демона
`WSGILazyInitialization On\|Off`	`WSGILazyInitialization On`	`server config`	Устанавливает, будет ли интерпретатор Python предварительно инициализирован в родительском процессе веб-сервера или будет выполнена «ленивая» (lazy) инициализация, при которой интерпретатор Python инициализируется только в процессах веб-сервера или процессах-демонах `mod_wsgi` после их форка из родительского процесса
`WSGIMapHEADToGET On\|Off\|Auto`	`WSGIMapHEADToGET Auto`	`server config`, `virtual host`, `directory`, `.htaccess`	Управляет поведением автоматического сопоставления любого запроса `HEAD` с запросом `GET`, когда зарегистрирован фильтр вывода веб-сервера, который может потребовать увидеть полный ответ для генерации правильных заголовков ответа. Директива может быть установлена в режим `Auto` (по умолчанию), `On` - всегда будет сопоставлять `HEAD` с `GET`, даже если не обнаружены фильтры вывода, и `Off` - чтобы всегда сохранять оригинальный тип метода запроса. Эта директива может быть необходима, когда WSGI-приложение пытается оптимизировать и избежать выполнения работы для запроса `HEAD`, не генерируя фактический ответ, чтобы полные заголовки ответа все еще могли быть сгенерированы. Таким образом WSGI-приложение может нарушить фильтры веб-сервера для кеширования, поэтому сопоставление `HEAD` с `GET` может быть необходимо для избежания проблем
`WSGIPassAuthorization On\|Off`	`WSGIPassAuthorization Off`	`server config`, `virtual host`, `directory`, `.htaccess`	Управляет тем, будут ли заголовки авторизации HTTP передаваться в WSGI-приложение в переменной `HTTP_AUTHORIZATION` окружения WSGI-приложения, когда соответствующие заголовки HTTP-запроса присутствуют. Установите в `On`, если авторизацию должно обрабатывать WSGI-приложение, а не веб-сервер. Заголовки авторизации по умолчанию не передаются, так как это может привести к утечке информации о паролях в WSGI-приложение, которое не должно их видеть, когда авторизацию выполняет веб-сервер. Если Apache HTTP Server выполняет авторизацию, WSGI-приложение может узнать, какой тип схемы авторизации использовался, проверив переменную `AUTH_TYPE` окружения WSGI-приложения. Имя пользователя авторизованного пользователя можно определить, проверив переменную `REMOTE_USER`
`WSGIProcessGroup %{GLOBAL}\|%{ENV:<variable>}\|<name>`	`WSGIProcessGroup %{GLOBAL}`	`server config`, `virtual host`, `directory`	Указывает, к какой группе процессов будет отнесено WSGI-приложение или набор приложений. Все WSGI-приложения в одной группе процессов будут выполняться в контексте одной и той же группы демон-процессов. Аргументом для `WSGIProcessGroup` может быть фактическое имя группы демон-процессов, настроенной с помощью директивы `WSGIDaemonProcess`, или одна из специальных переменных: - `%{GLOBAL}` - имя группы процессов будет установлено в пустую строку. Все WSGI-приложения в глобальной группе процессов будут выполняться в контексте стандартных дочерних процессов веб-сервера. - `%{ENV:<variable>}` - имя группы процессов будет установлено в значение указанной переменной окружения. Переменная окружения ищется через внутренние заметки веб-сервера и структуры данных окружения подпроцессов, а если не найдена, то через `getenv()` из процесса сервера Apache HTTP Server. При использовании директивы `WSGIProcessGroup` можно выбирать группы демон-процессов, определенные в виртуальных хостах с тем же именем сервера, или те, которые определены на глобальном уровне вне каких-либо виртуальных хостов. Невозможно выбрать группу демон-процессов, определенную в другом виртуальном хосте. Возможности выбора групп демон-процессов могут быть дополнительно ограничены, если была использована директива `WSGIRestrictProcess`
`WSGIPythonEggs <directory>`	Нет	`server config`	Указывает каталог, который будет использоваться в качестве кеша Python eggs для всех подпроцессоров, созданных во встроенном режиме. Эта директива достигает того же эффекта, что и установка переменной окружения `PYTHON_EGG_CACHE`. Обратите внимание, что указанный каталог должен существовать и быть доступным для записи пользователем, от имени которого работают дочерние процессы веб-сервера. Директива применяется только во встроенном режиме `mod_wsgi`. Для установки каталога кеша Python eggs для демон-процессов `mod_wsgi` используйте опцию `python-eggs` в директиве `WSGIDaemonProcess`
`WSGIPythonHome <prefix>\|<prefix>:<exec_prefix>`	Нет	`server config`	Указывает Python, где находятся установленные библиотечные файлы при его инициализации. Это следует определять, когда исполняемый файл Python не находится в `PATH` пользователя, от имени которого работает веб-сервер, или когда в системе установлено несколько версий Python в разных местах файловой системы, особенно разные установки одной и той же основной/минорной версии, и установка, которую веб-сервер находит в своем `PATH`, не является требуемой. Эта директива также может использоваться для указания виртуальной среды Python, созданной с помощью таких инструментов, как `virtualenv`, которая будет использоваться для всего `mod_wsgi`. При использовании этой директивы необходимо указать префикс для каталогов, содержащих платформенно-независимые и системно-зависимые библиотечные файлы Python. Каталоги должны быть разделены символом `:`. Если один и тот же каталог используется для обоих, то нужно указать только один путь к каталогу
`WSGIPythonOptimize [0\|1\|2]`	`WSGIPythonOptimize 0`	`server config`	Устанавливает уровень оптимизации компилятора Python. Значение по умолчанию — `0` - означает, что оптимизации не применяются. Установка уровня оптимизации на `1` или выше включает базовые оптимизации Python и изменяет расширение имени файла для скомпилированных (байт-кодовых) файлов с `.pyc` на `.pyo`
`WSGIPythonPath <directory>\|<directory-1>:<directory-2:…>`	Нет	`server config`	Указывает дополнительные каталоги для поиска Python-модулей. Если указано несколько каталогов, они должны быть разделены символом `:`. Если любая часть пути к каталогу содержит пробел, полная строка аргумента для `WSGIPythonPath` должна быть заключена в кавычки
`WSGIRestrictEmbedded On\|Off`	`WSGIRestrictEmbedded Off`	`server config`	Определяет, включен ли режим встраивания `mod_wsgi`. Если установлено значение `On` и ограничения на встроенный режим включены, любая попытка сделать запрос к WSGI-приложению, которое не было правильно настроено для делегирования в процесс-демон, завершится с ошибкой `HTTP 500` (внутренняя ошибка сервера)
`WSGIRestrictProcess <group-1> <group-2> …`	Нет	`server config`, `virtual host`, `directory`	Ограничивает выбор групп демон-процессов при использовании директивы `WSGIProcessGroup`. Группы демон-процессов, определенные в виртуальных хостах с тем же именем сервера, или те, которые определены на глобальном уровне вне каких-либо виртуальных хостов, могут быть выбраны. Невозможно выбрать группу демон-процессов, определенную в другом виртуальном хосте
`WSGIRestrictSignal On\|Off`	`WSGIRestrictSignal On`	`server config`	Позволяет включить/отключить ограничения на использование функции `signal()` WSGI-приложениями
`WSGIRestrictStdin On\|Off`	`WSGIRestrictStdin On`	`server config`	Позволяет включить/отключить ограничения на использование стандартного ввода (STDIN) WSGI-приложениями
`WSGIRestrictStdout On\|Off`	`WSGIRestrictStdout On`	`server config`	Позволяет включить/отключить ограничения на использование стандартного вывода (STDOUT) WSGI-приложениями
`WSGIScriptAlias <URL_path> <file_path>\|<directory_path> [ <options> ]`	Нет	`server config`, `virtual host`	Сопоставляет URL с местоположением в файловой системе и обозначает целевой путь как WSGI-скрипт. Директива `WSGIScriptAlias` ведет себя так же, как директива `Alias`, за исключением того, что она дополнительно помечает целевой каталог как содержащий WSGI-скрипты или помечает конкретный путь к файлу как скрипт, который должен обрабатываться обработчиком `wsgi-script` модуля `mod_wsgi`. Если целевым путем является `directory_path`, URL-адреса с чувствительным к регистру (%-декодированным) путем, начинающимся с `URL_path`, будут сопоставлены со скриптами, содержащимися в указанном каталоге. Возможные опции: - `process-group=<name>` - определяет, в какой группе процессов будет выполняться WSGI-приложение. Все WSGI-приложения в одной и той же группе процессов будут выполняться в контексте одной и той же группы процессов-демонов. Если имя установлено как `%{GLOBAL}`, имя группы процессов будет установлено в пустую строку. Любые WSGI-приложения в глобальной группе процессов всегда будут выполняться в контексте стандартных дочерних процессов веб-сервера. Такие WSGI-приложения будут иметь наименьшие накладные расходы во время выполнения, однако они будут делить одно и то же пространство процессов с другими модулями веб-сервера, такими как PHP, а также с процессом, используемым для обслуживания статического контента. Запуск WSGI-приложений в стандартных дочерних процессах веб-сервера также означает, что приложение будет работать от имени пользователя, от имени которого обычно работает Apache HTTP Server; - `application-group=<name>` - определяет, к какой группе приложений принадлежит WSGI-приложение или набор приложений. Все WSGI-приложения в одной и той же группе приложений будут выполняться в контексте одного и того же подинтерпретатора Python-процесса, обрабатывающего запрос. Если имя установлено как `%{GLOBAL}`, группа приложений будет установлена в пустую строку. Любые WSGI-приложения в глобальной группе всегда будут выполняться в контексте первого интерпретатора, созданного Python при его инициализации, и процесса, обрабатывающего запрос. Принудительный запуск приложения WSGI в первом интерпретаторе может потребоваться, когда сторонний модуль расширения C для Python использует упрощенный потоковый API для манипулирования GIL Python и, таким образом, не будет корректно запускаться в любых дополнительных интерпретаторах, созданных Python. Если заданы обе опции, файл сценария WSGI будет предварительно загружен при запуске процесса, в котором он должен выполняться, вместо того, чтобы загружаться «лениво» по первому запросу
`WSGIScriptAliasMatch <regex> <file_path>\|<directory_path> [ <options> ]`	Нет	`server config`, `virtual host`	Сопоставляет URL с местоположением в файловой системе и обозначает целевой путь как WSGI-скрипт. Эта директива аналогична директиве `WSGIScriptAlias`, но использует регулярные выражения вместо простого сопоставления префиксов. Указанное регулярное выражение сопоставляется с `URL_path`, затем, если оно совпадает, сервер подставляет любые совпадения в скобках в заданную строку и использует ее как имя файла
`WSGIScriptReloading On\|Off`	`WSGIScriptReloading On`	`server config`, `virtual host`, `directory`, `.htaccess`	Управляет тем, будут ли изменения в файлах WSGI-скриптов вызывать механизм перезагрузки. По умолчанию перезагрузка скриптов включена, и изменение файла WSGI-скрипта вызовет соответствующий механизм перезагрузки в зависимости от используемого режима
`WSGISocketPrefix <prefix>`	Нет	`server config`	Определяет каталог и префикс имени, которые будут использоваться для сокетов домена UNIX, используемых модулем `mod_wsgi` для связи между дочерними процессами веб-сервера и демон-процессами. Если директива не определена, сокеты и любые связанные файлы блокировки мьютексов будут помещены в стандартный каталог выполнения веб-сервера. Это тот же каталог, в который обычно помещаются файлы журналов Apache HTTP Server
`WSGITrustedProxies <ip_addr>\|(<ip_addr_1> <ip_addr_2> …)`	Нет	`server config`, `virtual host`, `directory`, `.htaccess`	Указывает один или список IP-адресов прокси-серверов, которые находятся перед экземпляром веб-сервера и считаются доверенными. Эта директива имеет эффект только в сочетании с директивой `WSGITrustedProxyHeaders`
`WSGITrustedProxyHeaders <header>\|(<header_1> <header_2> …)`	Нет	`server config`, `virtual host`, `directory`, `.htaccess`	Указывает один или список заголовков прокси, которые считаются доверенными. Когда доверенные прокси определены, эта директива указывает заголовки, которые используются для передачи информации от прокси к веб-серверу, находящемуся за прокси, и которые должны быть доверены. IP-адреса доверенных прокси должны быть указаны с помощью директивы `WSGITrustedProxies`