Qu'est-ce que Werkzeug exactement?
De la documentation officielle :
Werkzeug est une bibliothèque d'utilitaires WSGI pour Python.
Cependant, lorsque j'exécute mon Flask, je remarque que l'en-tête de réponse du serveur contient:
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
Sur la quatrième ligne, le serveur mentionne un Werkzeug, mais qu'est-ce que Werkzeug, est-ce un serveur Web comme Apache?
Non, ce n'est pas un serveur Web comme Apache. C'est une bibliothèque CGI. Étant donné qu'Apache (ou votre Flask) utilise probablement la bibliothèque pour servir certaines requêtes HTTP, il ajoute probablement cet en-tête dans la réponse.
Non ce n'est pas
Werkzeug (bibliothèque WSGI) est comme un communicateur entre votre code python et le serveur http nginx/Apache
Voici le cas d'utilisation complet de Werkzeug WSGI:
WSGI a deux côtés: le côté "serveur" ou "passerelle" (souvent un serveur Web comme Apache ou Nginx), et le côté "application" ou "framework" (le script Python lui-même) Pour traiter une demande WSGI, le côté serveur exécute l'application et fournit des informations d'environnement et une fonction de rappel au côté application. L'application traite la demande et renvoie la réponse au côté serveur à l'aide de la fonction de rappel qui lui a été fournie.
Entre le serveur et l'application, il peut y avoir un middleware WSGI, qui implémente les deux côtés de l'API. Le serveur reçoit une demande d'un client et la transmet au middleware. Après traitement, il envoie une demande à l'application. La réponse de l'application est transmise par le middleware au serveur et finalement au client. Il peut y avoir plusieurs middlewares formant une pile d'applications compatibles WSGI.
J'espère que ça aide
Werkzeug est principalement une bibliothèque, pas un serveur Web, bien qu'il fournisse un serveur Web simple à des fins de développement. Ce serveur de développement est ce qui fournit cet en-tête Server:.
Pour entrer dans les détails:
Tout d'abord, parlons de WSGI. Il y a un tas de serveurs Web là-bas, comme Apache, Nginx, Lighttpd, etc. Il y a aussi un tas de frameworks Web écrits en Python, par ex. Django, Flask, Tornado, Pyramid, etc. Ce serait terriblement pratique si tous étaient interopérables. C'est là qu'intervient WSGI. L'idée est la suivante:
Il y a deux côtés impliqués dans la réponse à la requête HTTP d'un client: le serveur Web et l'application Web . Le serveur gère les subtilités des connexions réseau, reçoit la demande et envoie la réponse. L'application prend les données de la demande, y réagit et crée la réponse que le serveur doit renvoyer.
Si vous souhaitez écrire une application Web Python, assurez-vous qu'elle possède un objet appelable (comme une fonction) qui accepte certains paramètres pour les en-têtes HTTP, les données de formulaire d'entrée, les variables d'environnement, etc.
Si vous souhaitez écrire un serveur Web qui sert des applications Python, faites-le appeler cet objet appelable à partir de l'application chaque fois qu'une demande HTTP arrive.
La spécification WSGI (in PEP 33 ) spécifie exactement quels doivent être les paramètres de cet appelable et quelle doit être la valeur de retour, afin que chaque serveur sache comment parler à chaque application et vice versa.
Ainsi, nous savons que chaque application Web doit fournir cet appelable et être capable de gérer les paramètres spécifiques qu'elle reçoit. Chaque application doit le faire ... Cela semble être une bonne occasion d'utiliser une bibliothèque. Werkzeug est cette bibliothèque.
Werkzeug fournit un tas d'utilitaires pour développer des applications compatibles WSGI. Ces utilitaires font des choses comme analyser les en-têtes, envoyer et recevoir des cookies, fournir un accès aux données du formulaire, générer des redirections, générer des pages d'erreur quand il y a une exception, même fournir un débogueur interactif qui s'exécute dans le navigateur. C'est vraiment assez complet. Flask s'appuie ensuite sur cette fondation (et Jinja, Click, etc.) pour fournir un cadre Web complet.
Donc, si Werkzeug est une bibliothèque pour applications, pourquoi apparaît-elle dans l'en-tête du serveur?
Werkzeug oui possède également un module pour le rôle serveur. Ceci est purement à des fins de commodité.
L'installation et la configuration d'un serveur Web à part entière comme Apache ou Nginx demande beaucoup d'efforts, et certainement une surpuissance juste pour tester votre application sur votre propre boîte de développement. Pour cette raison, Werkzeug fournit un serveur de développement: un simple serveur Web que vous pouvez exécuter avec une seule commande et presque aucune configuration. Lorsque vous faites flask run (Ou werkzeug.serving.run_simple()), ce serveur de développement est ce que vous obtenez. Et l'en-tête Server: Pour le serveur de développement est - vous l'avez deviné - Werkzeug/<version> Python/<version>.
Ce serveur n'est pas destiné à une utilisation en production. À tout le moins, selon les documents, il ne évolue pas bien. Mais je ne serais pas surpris s'il y avait aussi d'autres préoccupations, comme la sécurité.
Parce que non.
Dans votre configuration, vous utilisez probablement le "serveur de développement" (le run_simple fonction) pour les tests. C'est donc dans ce cas d'utilisation comme le Apache d'un (très) pauvre homme, mais seulement dans le sens où il est capable de répondre correctement aux requêtes HTTP.
Si vous vérifiez les documents http://werkzeug.pocoo.org/docs/serving/ , vous verrez la note suivante:
Le serveur de développement n'est pas destiné à être utilisé sur des systèmes de production. Il a été conçu spécialement à des fins de développement et fonctionne mal sous une charge élevée. Pour les configurations de déploiement, consultez les pages de déploiement d'application.