Was genau ist Werkzeug?


74

Aus der offiziellen Dokumentation :

Werkzeug ist eine WSGI-Dienstprogrammbibliothek für Python.

Wenn ich jedoch meine Flask-Webanwendung ausführe, stelle ich fest, dass der Antwortheader vom Server Folgendes enthält:

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

In der vierten Zeile erwähnt der Server a Werkzeug, aber wie genau ist es Werkzeug, wie ein Webserver Apache?

Antworten:


14

Nein, es ist kein Webserver wie Apache. Es ist eine CGI-Bibliothek. Da Apache (oder Ihre Flask-Anwendung) die Bibliothek wahrscheinlich verwendet, um einige HTTP-Anforderungen zu bearbeiten, fügt es diesen Header wahrscheinlich der Antwort hinzu.


Gibt es eine Methode, um den genauen Server zu überprüfen, den die Webanwendung verwendet? Ich dachte, dass der Anforderungsheader den Server in einer Server:Zeile anzeigen würde .
Jinglei

Normalerweise ist der Inhalt des "Server" -Headers korrekt. Aber denken Sie daran, dass jemand, der diese Informationen verbergen möchte, diesen Header leicht in einen beliebigen Header ändern kann (wenn er den Webserver betreibt)
Pablo Santa Cruz,

In diesem Fall sind die Header-Informationen höchstwahrscheinlich korrekt. Da werkzeugwird mit einem kleinen Entwicklungswebserver ausgeliefert - was wahrscheinlich die obige Antwort hervorgebracht hat. Wir werden nur sicher wissen, ob das OP sein Setup etwas detaillierter erklärt ...
Sebastian

3
Werkzeug ist keine CGI-Bibliothek. Es ist eine WSGI-Anwendungsbibliothek. Es gibt große Unterschiede zwischen CGI und WSGI.
Martijn Pieters

Ist das werkzueg der Kolbenentwicklungsserver?
Variable

103

Werkzeug ist in erster Linie eine Bibliothek, kein Webserver, obwohl es einen einfachen Webserver für Entwicklungszwecke bietet. Dieser Entwicklungsserver stellt diesen Server:Header bereit.

Um näher darauf einzugehen:

Lassen Sie uns zunächst über WSGI sprechen. Es gibt eine Reihe von Webservern wie Apache, Nginx, Lighttpd usw. Es gibt auch eine Reihe von in Python geschriebenen Webframeworks, z. B. Django, Flask, Tornado, Pyramid usw. Es wäre schrecklich praktisch, wenn dies der Fall wäre alles interoperabel. Hier kommt WSGI ins Spiel. Die Idee ist folgende:

  • Bei der Beantwortung der HTTP-Anfrage eines Clients sind zwei Seiten beteiligt: ​​der Webserver und die Webanwendung . Der Server kümmert sich um die Feinheiten der Netzwerkverbindungen, empfängt die Anforderung und sendet die Antwort. Die Anwendung nimmt die Anforderungsdaten entgegen, verarbeitet sie und erstellt die Antwort, die der Server zurücksenden soll.

  • Wenn Sie eine Python-Webanwendung schreiben möchten, stellen Sie sicher, dass sie über ein aufrufbares Objekt (z. B. eine Funktion) verfügt, das bestimmte Parameter für HTTP-Header, Eingabeformulardaten, Umgebungsvariablen usw. akzeptiert.

  • Wenn Sie einen Webserver schreiben möchten, der Python-Apps bereitstellt, rufen Sie dieses aufrufbare Objekt jedes Mal aus der Anwendung auf, wenn eine HTTP-Anforderung eingeht.

  • Die WSGI-Spezifikation (in PEP 3333 ) gibt genau an, welche Parameter für diesen aufrufbaren Wert erforderlich sind und wie hoch der Rückgabewert sein soll, damit jeder Server weiß, wie er mit jeder Anwendung kommunizieren kann und umgekehrt.

Wir wissen also, dass jede Webanwendung diese aufrufbare Funktion bereitstellen und in der Lage sein muss, die spezifischen Parameter zu verarbeiten, die sie empfängt. Jede Anwendung muss dies tun ... Das klingt nach einer guten Gelegenheit, eine Bibliothek zu verwenden. Werkzeug ist diese Bibliothek.

Werkzeug bietet eine Reihe von Dienstprogrammen für die Entwicklung von WSGI-kompatiblen Anwendungen. Diese Dienstprogramme analysieren beispielsweise Header, senden und empfangen Cookies, ermöglichen den Zugriff auf Formulardaten, generieren Weiterleitungen, generieren Fehlerseiten, wenn es eine Ausnahme gibt, und stellen sogar einen interaktiven Debugger bereit, der im Browser ausgeführt wird. Es ist wirklich ziemlich umfassend. Flask baut dann auf dieser Grundlage (und Jinja, Click usw.) auf, um ein vollständiges Webframework bereitzustellen.

Wenn Werkzeug eine Bibliothek für Anwendungen ist , warum wird sie dann im Server-Header angezeigt?

Werkzeug hat auch ein Modul für die Serverrolle. Dies dient lediglich der Bequemlichkeit.

Das Installieren und Konfigurieren eines vollwertigen Webservers wie Apache oder Nginx ist sehr aufwändig und mit ziemlicher Sicherheit übertrieben, nur um Ihre Anwendung auf Ihrer eigenen Entwicklungsbox zu testen. Aus diesem Grund bietet Werkzeug einen Entwicklungsserver: einen einfachen Webserver, den Sie mit einem einzigen Befehl und fast ohne Konfiguration ausführen können. Wenn Sie dies tun flask run(oder werkzeug.serving.run_simple()), erhalten Sie diesen Entwicklungsserver. Und der Server:Header für den Entwicklungsserver lautet - Sie haben es erraten - Werkzeug/<version> Python/<version>.

Dieser Server ist nicht für die Produktion bestimmt. Zumindest ist es laut Dokumentation nicht gut skalierbar. Aber ich wäre nicht überrascht, wenn es auch andere Bedenken gäbe, wie zum Beispiel die Sicherheit.


30

Nein, ist es nicht

Werkzeug (WSGI-Bibliothek) ist wie ein Kommunikator zwischen Ihrem Python-Code und dem http nginx / apache-Server

Hier ist der vollständige Anwendungsfall von Werkzeug WSGI:

WSGI hat zwei Seiten: die Seite "Server" oder "Gateway" (häufig ein Webserver wie Apache oder Nginx) und die Seite "Anwendung" oder "Framework" (das Python-Skript selbst). Um eine WSGI-Anforderung zu verarbeiten, führt die Serverseite die Anwendung aus und stellt der Anwendungsseite Umgebungsinformationen und eine Rückruffunktion zur Verfügung. Die Anwendung verarbeitet die Anforderung und gibt die Antwort mithilfe der bereitgestellten Rückruffunktion an die Serverseite zurück.

Zwischen dem Server und der Anwendung befindet sich möglicherweise eine WSGI-Middleware, die beide Seiten der API implementiert. Der Server empfängt eine Anfrage von einem Client und leitet sie an die Middleware weiter. Nach der Verarbeitung wird eine Anfrage an die Anwendung gesendet. Die Antwort der Anwendung wird von der Middleware an den Server und schließlich an den Client weitergeleitet. Es können mehrere Middlewares vorhanden sein, die einen Stapel von WSGI-kompatiblen Anwendungen bilden.

Ich hoffe es hilft


17

Weil es nicht so ist.

In Ihrem Setup verwenden Sie höchstwahrscheinlich den "Entwicklungsserver" (die run_simpleFunktion) zum Testen. In diesem Anwendungsfall ist es also wie bei einem (sehr) armen Mann Apache, aber nur in gewissem Sinne, dass es in der Lage ist, HTTP-Anfragen korrekt zu beantworten.

Wenn Sie die Dokumente http://werkzeug.pocoo.org/docs/serving/ überprüfen , wird der folgende Hinweis angezeigt:

Der Entwicklungsserver ist nicht für die Verwendung auf Produktionssystemen vorgesehen. Es wurde speziell für Entwicklungszwecke entwickelt und arbeitet unter hoher Last schlecht. Informationen zu Bereitstellungs-Setups finden Sie auf den Seiten zur Anwendungsbereitstellung.


-6

Flask Python verwendet Werkzeurg als Webserver zum Testen


6
Dies ist kaum eine nützliche Antwort. Sicherlich verglichen mit den anderen Antworten schon hier.
Martijn Pieters
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.