Что такое wsgi и зачем он нужен

Введение в WSGI-серверы: Часть первая

Данная статья является переводом статьи Кевина Голдберга «An Introduction to Python WSGI Servers: Part 1» blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 с небольшими дополнениями от переводчика

Краткая история серверов WSGI Python

WSGI-серверы появились потому, что веб-серверы в то время не умели взаимодействовать с приложениями, написанными на языке Python. WSGI (произносится как «whiz-gee» с твердым «g») был разработан Филиппом Дж. Эби (вместе с Ян Бикинг и др.) В начале 2000-х годов. Модуль Apache, известный как mod_python, разработанный Григорием Трубецким в конце 90-х годов, на тот момент обрабатывал большую часть Python-приложений. Однако mod_python не был официальной спецификацией. Он был просто создан, чтобы разработчики могли запускать код Python на сервере. К сожалению, такой подход был небезопасным и разработчики начали искать новое решение.

WSGI(Web-Server Gateway Interface) является потомком CGI(Common Gateway Interface). Когда веб начал развиваться, CGI разрастался из-за поддержки огромного количества языков и из-за отсутствия других решений. Однако, такое решение было медленным и ограниченным. WSGI был разработан как интерфейс для маршрутизации запросов от веб-серверов(Apache, Nginx и т.д.) на веб-приложения.

Сервер и веб-приложение

В простейшем случае WSGI состоит из двух основных сущностей:

Принцип работы:

Веб-сервер исполняет код и отправляет связанную с http-запросом информацию и callback-функцию в веб-приложение. Затем запрос на стороне приложения обрабатывается и высылается ответ на веб-сервер.

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

Вот примеры фреймворков, поддерживающих WSGI:

Почему именно WSGI?

Возможно Вы спросите «Хорошо, но почему именно WSGI?». На это есть несколько причин:

Bjoern

Bjoern — это асинхронный WSGI-сервер, написанный на C. Написанный с нуля, чтобы быть небольшим и быстрым, он был разработан с использованием http_parser от Райана Даля (создателя Node.js) и цикла событий Libev от Марка Леманна.
С размером загрузки всего 18 КБ он состоит из менее 800 строк кода. Он занимает менее 1 МБ оперативной памяти и не использует корутины или потоки. Bjoern полностью совместим с WSGI и считается одним из самых высокопроизводительных WSGI-серверов.
Bjoern поддерживает постоянные соединения и может привязываться к Unix-сокетам или TCP-адресам. Bjoern считается более быстрым, чем Gunicorn, и менее раздутым, чем uWSGI и Meinheld. Один из недостатков данного сервера — отсутствие нормальной документации с понятными примерами.

uWSGI

uWSGI был разработан компанией Unbit(Италия) с целью стать fullstack-решением, способным создавать услуги хостинга. Он назван в честь стандарта WSGI и создавался как плагин для одного из проектов компании.

Широкий и постоянно развивающийся проект, uWSGI позволяет делать гораздо больше, чем веб-приложения для хостинга. Многие находят uWSGI мощным инструментом, в то время как другие считают его несколько раздутым. Начиная с версии 2.0 uWSGI поддерживает также запуск веб-приложений на языках Lua, Perl, Ruby и других.

mod_wsgi

mod_wsgi — модуль HTTP-сервера Apache, разработанный Грэмом Дамплтоном (ранее, один из разработчиков mod_python), предоставляет интерфейс WSGI для веб-приложений. Совместим с версиями языка Python2 и Python3. Создан в качестве альтернативы другим решениям для интеграции веб-приложений, таких как CGI, FastCGI и mod_python. Может быть установлен как модуль Apache или через mod_wsgi express. Второй способ упрощает установку для разработчиков Python, которые не так хорошо знакомы с Apache. Другие преимущества:

• Вы не нуждаетесь в root-правах при полной установке.
• Создается локальная среда, что снижает риск негативного воздействия на существующие настройки.

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

В настоящее время основное внимание уделяется упрощению реализации Apache с использованием mod_wsgi в средах с использованием Docker.

Meinheld

Созданный Ютака Мацубара, Meinheld является сервером, совместимым с WSGI, который использует мощь picoev и greenlet для выполнения асинхронных операций ввода-вывода. Он может использоваться с автономным HTTP-сервером или через Gunicorn.

Meinheld имеет зависимость от стороннего компонента, называемого greenlet.

Репозиторий с исходным кодом расположен на GitHub. Meinheld поддерживает веб-сокеты и включает в себя несколько monkeypatches над другими модулями для расширения функциональности.

CherryPy

CherryPy — более известен как минималистичный Python-фреймворк для написания веб-приложений, CherryPy также поставляется с WSGI thread-pooled веб-сервером и поддержкой протокола HTTP / 1.1. Команда разработчиков CherryPy описывает свой веб-сервер как production-ready, высокоскоростной, thread-pooled HTTP-сервер. Он имеет:

• Быструю, простую настройку;
• Возможность масштабирования;
• Небольшое и простое в использовании решение для ваших приложений Python;
• Поддержка SSL.

CherryPy отличает себя от более известных WSGI-серверов из-за простоты использования и удобства для разработчиков. Вы можете написать небольшое веб-приложение в течении нескольких минут, запустив его в несколько процессов и создав только один файл с именем server.py. Объединив CherryPy с Nginx в качестве прокси-сервера, Вы получите надежный способ обслуживания своих веб-приложений. CherryPy был создан Реми Делоном. Он хотел создать структуру, которая была бы максимально близка к главным принципам разработки на языке Python.

Gunicorn

Gunicorn — это WSGI-сервер, созданный для использования в UNIX-системах. Название — сокращенная и комбинированная версия слов «Green Unicorn». На самом сайте проекта есть зеленый единорог. Gunicorn был перенесен из проекта «Unicorn» из языка Ruby. Он относительно быстрый, ресурсоёмкий, легко запускается и работает с широким спектром веб-фреймворков.

Команда разработчиков рекомендует использовать Gunicorn в связке с Nginx, где Nginx используется в качестве прокси-сервера.

Источник

Впервые было опубликовано в журнале «Системный администратор» #12 за 2008 год

Если вы разрабатываете Web-приложение, каркас для разработки Web-приложений, или даже Web-сервер на Python вам просто необходимо знание основ протокола WSGI — стандартного способа связи Web-сервера и Web-приложения.

Описание протокола

WSGI (расшифровывается как Web Server Gateway Interface — интерфейс шлюза Web-сервера) — это простой и универсальный интерфейс взаимодействия между Web-сервером и Web-приложением, впервые описанный в PEP-333 (http://www.python.org/dev/peps/pep-0333/). Под простотой в данном случае подразумевается лишь простота подключения приложения, но не простота реализации Web-приложений для авторов. Надо заметить, что основной целью разработки WSGI была разработка простого протокола, который бы мог разделить выбор каркасов для разработки Web-приложений от выбора Web-серверов. Это, в частности, позволяет разработчикам приложений (каркасов) и серверов концентрироваться на своей области специализации и отличает WSGI от более общих протоколов связи приложений с Web-серверами, таких как CGI, или FastCGI. С точки зрения WSGI цельное Web-приложение делится на две части: сервер (или шлюз) и непосредственно приложение (или каркас для построения приложений). Для обращения к приложению серверная часть использует вызываемый объект (это может быть функция, метод, класс, или экземпляр класса с методом __call__). WSGI также позволяет создавать приложения-посредники которые являются приложением для Web-сервера и сервером для Web-приложения. Такие посредники могут использоваться для предварительной обработки запросов к приложению, или последующей обработки его ответов. Ниже мы рассмотрим несколько примеров использования WSGI и затем обратимся к деталям протокола.

Сторона приложения

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

Здесь функция использует второй аргумент для передачи статуса и заголовков ответа и затем возвращает тело ответа в виде списка строк. Второе приложение реализовано в виде класса:

В данном случае объект класса будет представлять из себя итератор который на первом шаге итерации использует второй аргумент для передачи статуса и заголовков ответа и затем вернет тело ответа.

Надо отметить, что приложение с точки зрения WSGI — это всего лишь точка входа через которую сервер получает доступ к Web-приложению, или каркасу для построения Web-приложений.

Сторона сервера

Сервер (или шлюз) будет вызывать приложение для каждого HTTP запроса который ему предназначен. Для примера ниже представлен упрощенный шлюз CGI — WSGI. Пример использует упрощенную обработку ошибок т.к. по умолчанию ошибки будут выдаваться на sys.stderr и затем записываться в лог Web-сервера. Вызываемый объект приложения в данном случае передается как параметр функции:

Посредник: сервер и приложение в одном

Как уже было замечено выше некоторые объекты могут играть сразу две роли — быть сервером для какого-либо приложения и приложением для сервера. Вот примеры некоторых ситуаций для которых могут быть полезны WSGI-посредники:

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

Детали протокола

Как мы уже видели приложение должно принимать два аргумента, которые были названы environ и start_response, но могут иметь любые другие имена.

Первый параметр (environ) должен быть объектом словаря (dict) Python и содержит переменные среды похожие на переменные CGI. Этот объект также должен содержать обязательные для WSGI параметры, которые мы подробнее рассмотрим ниже, и может содержать переменные специфичные для конкретного Web-сервера.

Второй параметр (start_response) — это вызываемый объект которым приложение предваряет возвращение тела ответа и принимающий два обязательных параметра и один необязательный. Первый параметр (status) — статус ответа в виде строки, например «200 Ok». Второй параметр (response_headers в примере выше) — список кортежей (tuples) вида (имя_заголовка, значение_заголовка). Третий, необязательный параметр (exc_info) должен использоваться только при обработке ошибок и должен быть кортежем который возвращает функция sys.exc_info(). Надо заметить, что start_response не посылает заголовки сразу, а откладывает их до получения первой части тела ответа, что бы в случае ошибки их можно было заменить на заголовки сопутствующие ошибке. При этом start_response можно вызывать несколько раз только если передается третий параметр (exc_info).

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

В случае если итерируемый объект имеет метод close() он будет вызван по окончании обработки ответа сервером, даже в случае ошибки. Таким образом метод close() может использоваться для закрытия всех ресурсов приложения которые могли быть задействованы при создании ответа.

Переменные словаря environ

Словарь environ может содержать следующие CGI переменные: (Переменные которые может содержать словарь environ)

Также словарь environ должен содержать следующие, обязательные для WSGI переменные: (Обязательные для WSGI переменные в словаре environ)

Плюс environ может содержать специфичные для конкретного сервера переменные и переменные среды. Что бы увидеть набор переменных передаваемых приложению можно использовать, например, следующее простое WSGI приложение:

Обработка ошибок

В общем случае приложение должно обрабатывать внутренние ошибки и выводить соответствующее сообщение клиенту. Конечно, прежде чем выводить сообщение об ошибке приложение не должно начинать выводить нормальный ответ. Что бы обойти эту ситуацию используется третий параметр start_response — exc_info:

Если приложение еще не начало вывод тела ответа когда произошло исключение, то вызов start_response в обработчике будет нормальным и клиенту вернется ответ об ошибке. В случае если на момент ошибки уже был начат вывод ответа start_response выкинет переданное исключение. Это исключение не должно обрабатываться обработчиком, а будет обработано сервером и записано в журнал ошибок.

Пакет wsgiref

В стандартной библиотеке Python 2.5 появился новый пакет wsgiref, предоставляющий различные утилиты для упрощения работы с WSGI. Рассмотрим кратко его содержимое:

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

WSGI (Web Server Gateway Interface)

Содержание

Обзор

История

Традиционный веб-сервер не имеет возможности запускать приложения Python. В конце 1990-х был предложен модуль Apache mod_python для выполнения произвольного кода Python. В течение нескольких лет в конце 1990-х и начале 2000-х годов Apache, настроенный с помощью mod_python, запускал большинство веб-приложений Python. Тем не менее, mod_python не был стандартной спецификацией. Это была просто реализация, которая позволяла запускать код Python на сервере. Когда разработка mod_python зашла в тупик и были обнаружены уязвимости безопасности, сообщество признало, что необходим последовательный способ выполнения кода Python для веб-приложений. Поэтому сообщество Python разработало WSGI в качестве стандартного интерфейса, который могут реализовывать модули и контейнеры. WSGI теперь является общепринятым подходом для запуска веб-приложений Python.

Описание

WSGI отличается гибкостью: разработчики приложений могут заменять компоненты веб-стека другими. Например, разработчик может перейти с Green Unicorn на WSGI без изменения приложения или инфраструктуры, реализующей WSGI. Согласно PEP 333: «Доступность и широкое использование такого API в веб-серверах для Python [. ] отделяет выбор среды от выбора веб-сервера, [. ] позволяя разработчикам сосредоточиться на их предпочтительной области специализации». [Источник 1]

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

Согласно спецификации PEP 333 [Источник 2] :

Приложение WSGI

Объект приложения должен принимать два позиционных аргумента: environment и start_response. Сервер или шлюз должны вызывать объект приложения, используя позиционные (не ключевые) аргументы.

Параметр environment является объектом словаря, содержащим переменные среды в стиле CGI. Этот объект должен быть встроенным словарем Python (не подклассом, UserDict или другой эмуляцией словаря), и приложению разрешается изменять словарь любым способом, который он пожелает. Словарь также должен включать определенные переменные, необходимые для WSGI (описанные в следующем разделе), и может также включать переменные расширения, специфичные для сервера, названные в соответствии с соглашением, которое будет описано ниже.

Вызываемый элемент start_response должен возвращать вызываемый объект write (body_data), который принимает один позиционный параметр: строку, которая должна быть записана как часть тела ответа HTTP.

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

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

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

Пример WSGI-совместимого приложения:

Приложение возвращает итератор с телом ответа, проще говоря – массив строк, которые будут склеены и отправлены в браузер. [Источник 3]

Промежуточное программное обеспечение WSGI

Как уже говорилось, один объект может играть роль сервера по отношению к некоторым приложениям, а также выполнять роль приложения по отношению к некоторым серверам. Такие «промежуточные» компоненты могут выполнять такие функции как:

Наличие промежуточного программного обеспечения в целом прозрачно как для стороны «сервер / шлюз», так и для «приложения / фреймворк» интерфейса, и не требует специальной поддержки. Пользователь, который хочет встроить промежуточное программное обеспечение в приложение, просто предоставляет компонент промежуточного программного обеспечения серверу, как если бы это было приложение, и настраивает компонент промежуточного программного обеспечения для вызова приложения, как если бы компонент промежуточного программного обеспечения был сервером. Конечно, «приложение», которое связывает промежуточное программное обеспечение, может фактически быть другим компонентом промежуточного программного обеспечения, обертывающим другое приложение, и так далее, создавая так называемый «стек промежуточного программного обеспечения».

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

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

Это требование гарантирует, что асинхронные приложения и серверы могут сговориться, чтобы уменьшить количество потоков, необходимых для одновременного запуска определенного количества экземпляров приложения.

Источник

Русские Блоги

python WSGI

Что такое WSGI

Зачем нам нужна спецификация WSGI

Что касается решений веб-развертывания, наиболее широко используется одно из них:

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

Затем разверните приложение, написанное на разных языках (Java, PHP, Python, Ruby и т. Д.). Это приложение будет получать запрос клиента от веб-сервера. После завершения обработки ответ будет возвращен в Интернет. Сервер возвращается к клиенту.

Как работает WSGI

Как видно из вышеизложенного, WSGI эквивалентен мосту между веб-сервером и приложением Python. Так как же работает этот мост? Прежде всего, мы проясним роль моста. WSGI существует для двух целей:

Сообщите веб-серверу, как вызвать приложение Python, и сообщите приложению запрос пользователя.

Сообщите приложению Python, что представляет собой конкретный запрос пользователя и как вернуть результат на веб-сервер.

Роли в WSGI

В WSGI определены две роли, сторона веб-сервера называетсяserverили жеgateway, Сторона приложения называетсяapplicationили жеframework(Поскольку спецификации WSGI на стороне приложения обычно реализуются конкретными фреймворками). Ниже мы единообразно используем два термина: сервер и приложение.

Сторона сервера сначала получит запрос пользователя, а затем вызовет сторону приложения в соответствии со спецификациями, как показано на следующем рисунке:

Результат вызова будет инкапсулирован в HTTP-ответ, а затем отправлен клиенту.

Как сервер вызывает приложение

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

В приведенном выше коде environ с участием start_response Вызывается на стороне сервераapplicationКогда объект.

Используйте стандартную библиотеку (это просто демонстрация)

Используйте фреймворк web.py

Как видите, в файле должен быть такойapplicationObject, сервер найдет этот файл и затем вызовет этот объект. Таким образом, фреймворки Python, поддерживающие WSGI, в конечном итоге будут иметь такой объект приложения, но пользователям фреймворка не нужно заботиться о том, как объект приложения работает внутри, только о конкретной бизнес-логике, такой как определение маршрута и обработка запросов.

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

Что должен делать объект приложения

Как упоминалось выше, объект приложения должен быть вызываемым объектом, а его определение должно соответствовать следующей форме:

параметр среды

SCRIPT_NAME: Часть пути HTTP-запроса, используемая для поиска объекта приложения. Например, веб-сервер может определить, какой виртуальный хост обрабатывает запрос на основе части пути.

PATH_INFO: Оставшаяся часть пути HTTP-запроса, которая будет обработана приложением.

QUERY_STRING: Строка запроса в HTTP-запросе в URL-адресе?Следующее содержание

CONTENT_TYPE: Контент типа содержимого в заголовках HTTP

CONTENT_LENGTH: Содержимое в заголовках HTTP

SERVER_NAMEс участиемSERVER_PORT: Имя сервера и порт, эти два значения могут быть объединены с предыдущим SCRIPT_NAME и PATH_INFO, чтобы получить полный путь URL

SERVER_PROTOCOL: Версия протокола HTTP, HTTP / 1.0 или HTTP / 1.1

HTTP_: Соответствует заголовкам в HTTP-запросе.

Спецификация WSGI также требует, чтобы окружение содержало следующие члены:

wsgi.version: Представляет версию WSGI, кортеж (1, 0), представляет версию 1.0

wsgi.url_scheme: Http или https

wsgi.input: Входной поток файла класса, приложение может получить тело HTTP-запроса через этот

wsgi.errors: Выходной поток, при возникновении ошибки приложения вы можете записать сюда информацию об ошибке

wsgi.multithread: Когда объект приложения может быть вызван несколькими потоками одновременно, это значение должно быть True.

wsgi.multiprocess: Когда объект приложения может быть вызван несколькими процессами одновременно, это значение должно быть True.

wsgi.run_once: Когда сервер ожидает, что объект приложения будет вызываться только один раз в жизненном цикле процесса, значение равно True.

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

параметры start_resposne

status: Строка, представляющая строку состояния ответа HTTP

response_headers: Список, содержащий кортежи следующей формы: (header_name, header_value), используемый для представления заголовков HTTP-ответа.

exc_info(Необязательно): используется для информации, которую сервер должен вернуть браузеру при возникновении ошибки.

Возвращаемое значение объекта приложения

Возвращаемое значение объекта приложения используется для предоставления тела ответа HTTP. Если тела нет, он может вернуть None. Если есть преобразование тела, то необходимо вернуть итеративный объект. Сторона сервера может получить все содержимое тела, пройдя этот итерационный объект.

application demo

В PEP-3333 есть демонстрация реализации приложения, я упростил ее следующим образом:

Вы можете сравнить этот код с предыдущим описанием.

Поговорим о том, как сервер вызывает приложение

Я уже знал, как сервер определяет вход приложения, а также форму входа приложения и работы, которые необходимо выполнить внутри объекта приложения. Итак, нам нужно сказать еще кое-что, environ с участием start_response() Его необходимо сгенерировать и определить на стороне сервера, что составляет примерно start_response() Деталь также имеет четкие требования в спецификации. Эта часть содержания слишком длинна для включения в эту статью. Заинтересованные читатели могут перейти к PEP-3333, который содержит демонстрационную реализацию на стороне сервера.

Промежуточное ПО WSGI

Мы можем использовать следующий рисунок, чтобы проиллюстрировать, как работает промежуточное ПО:

Три верхних цветных прямоугольника на рисунке выше представляют роли, а белые прямоугольники посередине представляют собой операции. Порядок выполнения операций отсортирован от 1 до 5. Мы непосредственно проиллюстрируем, как работает промежуточное программное обеспечение, обратившись к приведенному выше рисунку:

После того, как сервер получает HTTP-запрос от клиента, он генерирует environ_s И определил start_response_s 。

Сервер вызывает объект приложения Middleware, передаваемые параметры environ_s с участием start_response_s 。

Промежуточное ПО будет основано на environ Выполнить бизнес-логику и сгенерировать environ_m И определил start_response_m 。

Из описанного выше процесса можно увидеть несколько характеристик приложений промежуточного слоя:

Сервер считает промежуточное ПО приложением.

Приложение считает промежуточное ПО сервером.

Промежуточное ПО может иметь несколько уровней.

Поскольку промежуточное ПО может обрабатывать все прошедшие запросы и ответы, оно может делать все, что угодно, без ограничений. Например, вы можете проверить, есть ли в запросе недопустимое содержимое, проверить, есть ли в ответе недопустимое содержимое, и добавить к запросу определенный HTTP-заголовок. Все это возможно.

Внедрение и развертывание WSGI

Чтобы использовать WSGI, вам необходимо реализовать роль сервера и роль приложения соответственно.

Реализация на стороне приложения обычно реализуется различными фреймворками Python, такими как Django, web.py и т. Д. Обычно разработчикам не нужно заботиться о реализации WSGI, фреймворк предоставляет разработчикам интерфейсы для получения содержимого HTTP-запросов и отправлять HTTP-ответы.

Реализация на стороне сервера будет немного сложнее, в основном из-за архитектуры программного обеспечения. Часто используемые веб-серверы, такие как Apache и nginx, не имеют встроенной поддержки WSGI, но дополняются расширениями. Например, сервер Apache будет поддерживать WSGI через модуль расширения mod_wsgi. Информация передается между Apache и mod_wsgi через внутренний интерфейс программы Mod_wsgi реализует серверную часть WSGI, управление процессами и вызовы приложений. Nginx обычно использует метод прокси для инкапсуляции запроса с протоколом nginx и отправки его на сервер приложений, такой как uWSGI. Сервер приложений будет реализовывать сервер WSGI, управление процессами и вызовы приложений.

Источник