Werkzeug — это служебная библиотека WSGI для Python.
Однако, когда я запускаю свое веб-приложение Flask, я замечаю, что заголовок ответа с сервера содержит:
HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 13
Server: Werkzeug/0.11.9 Python/2.7.10
Date: Tue, 03 May 2016 12:50:08 GMT
В четвертой строке сервер упоминает Werkzeug, но что такое Werkzeug, это веб-сервер, подобный Apache?
Нет, это не веб-сервер, как Apache. Это библиотека CGI. Поскольку Apache (или ваше приложение Flask), вероятно, использует библиотеку для обслуживания некоторых HTTP-запросов, он, вероятно, добавляет этот заголовок в ответ.
Server:.
- person jinglei; 03.05.2016
werkzeug поставляется с небольшим веб-сервером для разработки, что, вероятно, и привело к приведенному выше ответу. Мы узнаем наверняка только в том случае, если ОП объяснит его настройку более подробно ...
- person sebastian; 03.05.2016
Werkzeug — это в первую очередь библиотека, а не веб-сервер, хотя он предоставляет простой веб-сервер для целей разработки. Этот сервер разработки предоставляет заголовок Server:.
Подробнее:
Во-первых, давайте поговорим о WSGI. Существует множество веб-серверов, таких как Apache, Nginx, Lighttpd и т. д. Также существует множество веб-фреймворков, написанных на Python, например. Django, Flask, Tornado, Pyramid и т. д. Было бы ужасно удобно, если бы все они были совместимы. Вот тут-то и появляется WSGI. Идея такова:
В ответ на HTTP-запрос клиента вовлечены две стороны: веб-сервер и веб-приложение. Сервер обрабатывает тонкости сетевых подключений, получает запрос и отправляет ответ. Приложение принимает данные запроса, обрабатывает их и формирует ответ, который сервер отправляет обратно.
Если вы хотите написать веб-приложение Python, убедитесь, что оно имеет вызываемый объект (например, функцию), который принимает определенные параметры для заголовков HTTP, данных формы ввода, переменных среды и т. д.
Если вы хотите написать веб-сервер, обслуживающий приложения Python, заставьте его вызывать вызываемый объект из приложения каждый раз, когда приходит HTTP-запрос.
Спецификация WSGI (в PEP 3333) точно указывает, какие параметры для этого вызываемого объекта должно быть и каким должно быть возвращаемое значение, поэтому каждый сервер знает, как общаться с каждым приложением, и наоборот.
Итак, мы знаем, что каждое веб-приложение должно предоставлять этот вызываемый объект и иметь возможность обрабатывать определенные параметры, которые оно получает. Каждое приложение должно делать это... Похоже, это хорошая возможность использовать библиотеку. Werkzeug — это библиотека.
Werkzeug предоставляет набор утилит для разработки WSGI-совместимых приложений. Эти утилиты выполняют такие функции, как разбор заголовков, отправка и получение файлов cookie, предоставление доступа к данным формы, создание перенаправлений, создание страниц ошибок при возникновении исключения и даже предоставление интерактивного отладчика, который запускается в браузере. Это действительно довольно всеобъемлюще. Затем Flask строится на этом фундаменте (и Jinja, Click и т. д.), чтобы обеспечить полную веб-инфраструктуру.
Итак, если Werkzeug — это библиотека для приложений, почему она отображается в заголовке сервера?
У Werkzeug есть модуль для роли сервера. Это чисто для удобства.
Установка и настройка полноценного веб-сервера, такого как Apache или Nginx, требует больших усилий и почти наверняка является избыточным только для тестирования вашего приложения на вашей собственной среде разработки. По этой причине Werkzeug предоставляет сервер разработки: простой веб-сервер, который можно запустить с помощью одной команды и почти без настройки. Когда вы делаете flask run (или werkzeug.serving.run_simple()), вы получаете этот сервер разработки. И заголовок Server: для сервера разработки, как вы уже догадались, Werkzeug/<version> Python/<version>.
Этот сервер не предназначен для производственного использования. По крайней мере, согласно документам, он плохо масштабируется. Но я не удивлюсь, если есть и другие проблемы, например безопасность.
Нет, не
Werkzeug (библиотека WSGI) похож на коммуникатор между вашим кодом Python и сервером http nginx/apache.
Вот полный вариант использования Werkzeug WSGI:
WSGI имеет две стороны: сторону «сервера» или «шлюза» (часто это веб-сервер, такой как Apache или Nginx) и сторону «приложения» или «фреймворка» (сам скрипт Python). Чтобы обработать запрос WSGI, серверная сторона выполняет приложение и предоставляет информацию о среде и функцию обратного вызова на сторону приложения. Приложение обрабатывает запрос, возвращая ответ серверной части с помощью предоставленной ему функции обратного вызова.
Между сервером и приложением может быть промежуточное ПО WSGI, реализующее обе стороны API. . Сервер получает запрос от клиента и перенаправляет его промежуточному программному обеспечению. После обработки отправляет запрос в приложение. Ответ приложения перенаправляется промежуточным программным обеспечением на сервер и, в конечном счете, на клиент. Может быть несколько промежуточных программ, образующих стек WSGI-совместимых приложений.
Надеюсь, поможет
Потому что это не так.
В вашей настройке вы, скорее всего, используете «сервер разработки» (функция run_simple) для тестирования. Таким образом, в этом случае использования он похож на Apache (очень) бедного человека, но только в том смысле, что он может правильно отвечать на HTTP-запросы.
Если вы проверите документы http://werkzeug.pocoo.org/docs/serving/, вы увидите следующую заметку:
Сервер разработки не предназначен для использования в производственных системах. Он был разработан специально для целей разработки и плохо работает при высокой нагрузке. Информацию о настройках развертывания см. на страницах развертывания приложений.
Flask python использует werkzeurg в качестве веб-сервера для тестирования
