WSGI ist eine sehr einfache Spezifikation (PEP 333), die eigentlich auf das System der Generatoren aufbaut. Im Grunde genommen muss man folgende drei Dinge unterscheiden:
Contents
Application
Die Application, also die Anwendung, ist der für den Programmierer relevante Teil. Eine WSGI-Anwendung ist eigentlich nicht mehr als ein Generator, der mit zwei Parametern aufgerufen wird: dem environ und einer Referenz auf eine Funktion start_response.
Der zurückgeworfene Generator darf eine Methode close besitzen, die vom Wrapper aufgerufen wird, wenn die Anwendung geschlossen wird. Und das auch im Fehlerfall. Also ist das ein guter Ansatzpunkt, um beispielsweise Datenbankverbindungen in jedem Fall zu schließen.
Eine WSGI-Anwendung bekommt Parameter über das dict environ und sendet Daten mit Hilfe von start_response und yield1. start_response muss vor der ersten yield-Anweisung stehen.
environ enthält alle Variablen, die das WSGI-Protokoll zur Verfügung stellt. Zusätzlich können Middleware-Systeme hier eigene Konfigurationsvariablen ergänzen. Folgende Werte stehen immer zur Verfügung:
Schlüssel |
Beschreibung |
Beispielwert |
vorgeschrieben |
WSGI-Variablen |
|||
wsgi.version |
Version des verwendeten WSGI-Protokolls |
(1, 0) |
|
wsgi.url_scheme |
das URL-Schema (http, https oder ähnliches) |
http |
|
wsgi.input |
Input-Stream; enthält in der Regel die HTTP-POST-Parameter |
<type 'file'> |
|
wsgi.errors |
Error-Output-Stream; in der Regel ein Stream zum Webserver-Log |
<type 'file'> |
|
wsgi.multithread |
Boolean; ob die Anwendung in einem multithreaded Wrapper läuft |
False |
|
wsgi.multiprocess |
Boolean; ob der Wrapper mehrere Prozesse spawnt |
True |
|
wsgi.run_once |
Boolean; ob die Anwendung nach dem Aufruf terminiert oder weiterlebt |
False |
|
CGI-Variablen |
|||
SCRIPT_NAME |
absoluter Pfad bis zum PATH_INFO |
/myapplication |
|
QUERY_STRING |
URL-Parameter-String |
parameter=value&spam=eggs |
|
REQUEST_METHOD |
Die HTTP-Zugriffsmethode |
GET |
|
SERVER_NAME |
Der Servername |
localhost |
|
PATH_INFO |
PATH_INFO - virtueller Pfad |
/articles/23/ |
|
HTTP_COOKIE |
Client-Cookie |
sessionid=4e5027ee9156e193c1b07189b5d7c408 |
|
Dabei ist zu beachten, dass der Name "CGI-Variablen" etwas verwirren kann. Diese stehten unter jedem Wrapper zur Verfügung, nicht nur in CGI-Wrappern.
Bei Zeilen, in denen "required" nicht gesetzt ist, muss die Variable nicht unbedingt vorhanden sein, beispielsweise weil kein Cookie gesetzt ist.
Für genaue Informationen zur WSGI-Anwendungsentwicklung siehe WSGI Anwendungen.
Middleware
Eine Middleware ist eine Klasse, die zwischen Wrapper und Anwendung montiert wird. Diese kann beispielsweise den Anwendungsoutput ändern (beispielsweise Wörter hervorheben) oder das environ verändern (für Session-Middlewares).
Middlewares sind eigentlich auch nur Generatoren, die als Parameter eine Anwendung oder eine andere Middleware aufnehmen und in der __call__ Methode durch den Output der Anwendung/Middleware iterieren, irgendwas damit machen und dann wieder einen Generator zurückschicken.
Für genauere Informationen zur WSGI-Middleware-Entwicklung siehe WSGI Middlewares.
Wrapper
Wrapper sind Klassen, die eine WSGI-Anwendung letztendlich an ein Protokoll binden. Es gibt momentan Wrapper für CGI, FastCGI, SCGI und AJP im flup-Package. mod_python ist zur Zeit noch etwas problematisch, da der einzige brauchbare Wrapper ein nicht mehr gepflegtes Python-Paket benötigt.
Seit Python2.5 finden sich einige Wrapper auch in der Standard library (wsgiref).
Wer einen Wrapper entwickeln will, schaut sich am Besten das PEP dazu an.
Benutzer von Python2.2 müssen folgenden Import als erstes hinzufügen: from __future__ import generators (1)