wsgiref — WSGI-verktyg och referensimplementering

Källkod: Lib/wsgiref


Web Server Gateway Interface (WSGI) är ett standardgränssnitt mellan webbserverprogramvara och webbapplikationer skrivna i Python. Ett standardgränssnitt gör det enkelt att använda en applikation som stöder WSGI med ett antal olika webbservrar.

Endast författare av webbservrar och programmeringsramverk behöver känna till varje detalj och hörnfall i WSGI-designen. Du behöver inte förstå varje detalj i WSGI bara för att installera en WSGI-applikation eller för att skriva en webbapplikation med hjälp av ett befintligt ramverk.

wsgiref är en referensimplementering av WSGI-specifikationen som kan användas för att lägga till WSGI-stöd i en webbserver eller ett ramverk. Den innehåller verktyg för att manipulera WSGI-miljövariabler och svarshuvuden, basklasser för att implementera WSGI-servrar, en demo-HTTP-server som betjänar WSGI-applikationer, typer för statisk typkontroll och ett valideringsverktyg som kontrollerar att WSGI-servrar och applikationer överensstämmer med WSGI-specifikationen (PEP 3333).

Se wsgi.readthedocs.io för mer information om WSGI och länkar till handledningar och andra resurser.

wsgiref.util – Verktyg för WSGI-miljön

Denna modul innehåller en mängd olika funktioner för att arbeta med WSGI-miljöer. En WSGI-miljö är en ordbok som innehåller HTTP-begärandevariabler enligt beskrivningen i PEP 3333. Alla funktioner som tar en environ-parameter förväntar sig att en WSGI-kompatibel ordbok ska levereras; se PEP 3333 för en detaljerad specifikation och WSGIEnvironment för ett typalias som kan användas i typannoteringar.

wsgiref.util.guess_scheme(environ)

Returnerar en gissning om huruvida wsgi.url_scheme ska vara ”http” eller ”https”, genom att kontrollera om det finns en miljövariabel HTTPS i ordlistan environ. Returvärdet är en sträng.

Denna funktion är användbar när du skapar en gateway som omsluter CGI eller ett CGI-liknande protokoll som FastCGI. Servrar som tillhandahåller sådana protokoll innehåller vanligtvis en variabel HTTPS med värdet ”1”, ”yes” eller ”on” när en begäran tas emot via SSL. Den här funktionen returnerar alltså ”https” om ett sådant värde hittas och ”http” annars.

wsgiref.util.request_uri(environ, include_query=True)

Returnerar den fullständiga URI:n för begäran, eventuellt inklusive frågesträngen, med hjälp av algoritmen i avsnittet ”URL Reconstruction” i PEP 3333. Om include_query är false inkluderas inte frågesträngen i den resulterande URI:n.

wsgiref.util.application_uri(environ)

Liknar request_uri(), förutom att variablerna PATH_INFO och QUERY_STRING ignoreras. Resultatet är bas-URI:n för det applikationsobjekt som adresseras av begäran.

wsgiref.util.shift_path_info(environ)

Flytta ett enskilt namn från PATH_INFO till SCRIPT_NAME och returnera namnet. Ordboken environ är modifierad på plats; använd en kopia om du behöver behålla den ursprungliga PATH_INFO eller SCRIPT_NAME intakt.

Om det inte finns några återstående sökvägssegment i PATH_INFO returneras None.

Vanligtvis används denna rutin för att bearbeta varje del av en sökväg till en begärd URI, t.ex. för att behandla sökvägen som en serie ordboksnycklar. Den här rutinen modifierar den överlämnade miljön så att den lämpar sig för att anropa en annan WSGI-applikation som finns på mål-URI:n. Till exempel, om det finns en WSGI-applikation på /foo, och sökvägen till request URI är /foo/bar/baz, och WSGI-applikationen på /foo anropar shift_path_info(), kommer den att ta emot strängen ”bar”, och miljön kommer att uppdateras så att den passar för att skickas till en WSGI-applikation på /foo/bar. Det vill säga, SCRIPT_NAME ändras från /foo till /foo/bar, och PATH_INFO ändras från /bar/baz till /baz.

När PATH_INFO bara är ett ”/” returnerar den här rutinen en tom sträng och lägger till ett efterföljande snedstreck till SCRIPT_NAME, även om tomma sökvägssegment normalt ignoreras och SCRIPT_NAME normalt inte slutar med ett snedstreck. Detta är ett avsiktligt beteende för att säkerställa att ett program kan skilja mellan URI:er som slutar på /x och sådana som slutar på /x/ när den här rutinen används för objekttraversering.

wsgiref.util.setup_testing_defaults(environ)

Uppdatera environ med triviala standardvärden för teständamål.

Denna rutin lägger till olika parametrar som krävs för WSGI, inklusive HTTP_HOST, SERVER_NAME, SERVER_PORT, REQUEST_METHOD, SCRIPT_NAME, PATH_INFO och alla PEP 3333’-definierade wsgi.*-variabler. Den tillhandahåller endast standardvärden och ersätter inte befintliga inställningar för dessa variabler.

Denna rutin är avsedd att göra det enklare för enhetstester av WSGI-servrar och applikationer att skapa dummy-miljöer. Den ska INTE användas av faktiska WSGI-servrar eller applikationer, eftersom data är falska!

Exempel på användning (se även demo_app() för ett annat exempel):

from wsgiref.util import setup_testing_defaults
from wsgiref.simple_server import make_server

# A relatively simple WSGI application. It's going to print out the
# environment dictionary after being updated by setup_testing_defaults
def simple_app(environ, start_response):
    setup_testing_defaults(environ)

    status = '200 OK'
    headers = [('Content-type', 'text/plain; charset=utf-8')]

    start_response(status, headers)

    ret = [("%s: %s\n" % (key, value)).encode("utf-8")
           for key, value in environ.items()]
    return ret

with make_server('', 8000, simple_app) as httpd:
    print("Serving on port 8000...")
    httpd.serve_forever()

Förutom miljöfunktionerna ovan tillhandahåller modulen wsgiref.util även dessa olika verktyg:

wsgiref.util.is_hop_by_hop(header_name)

Returnerar True om ’header_name’ är en HTTP/1.1 ”Hop-by-Hop” header, enligt definitionen i RFC 2616.

class wsgiref.util.FileWrapper(filelike, blksize=8192)

En konkret implementering av protokollet wsgiref.types.FileWrapper som används för att konvertera ett filliknande objekt till en iterator. De resulterande objekten är iterables. När objektet itereras över kommer den valfria parametern blksize upprepade gånger att skickas till det filliknande objektets read()-metod för att få bytestrings att ge. När read() returnerar en tom bytestring är iterationen avslutad och kan inte återupptas.

Om filelike har en close()-metod kommer det returnerade objektet också att ha en close()-metod, och det kommer att anropa filelike-objektets close()-metod när den anropas.

Exempel på användning:

from io import StringIO
from wsgiref.util import FileWrapper

# We're using a StringIO-buffer for as the file-like object
filelike = StringIO("This is an example file-like object"*10)
wrapper = FileWrapper(filelike, blksize=5)

for chunk in wrapper:
    print(chunk)

Ändrad i version 3.11: Stöd för metoden __getitem__() har tagits bort.

wsgiref.headers – Verktyg för WSGI-svarshuvuden

Denna modul tillhandahåller en enda klass, Headers, för bekväm manipulation av WSGI-svarshuvuden med hjälp av ett mappningsliknande gränssnitt.

class wsgiref.headers.Headers([headers])

Skapa ett mappningsliknande objekt som omsluter headers, som måste vara en lista med headernamn/värde-tupler enligt beskrivningen i PEP 3333. Standardvärdet för headers är en tom lista.

Headers-objekt stöder typiska mappningsoperationer inklusive __getitem__(), get(), __setitem__(), setdefault(), __delitem__() och __contains__(). För var och en av dessa metoder är nyckeln rubriknamnet (behandlas utan hänsyn till skiftlägesskillnader) och värdet är det första värdet som associeras med rubriknamnet. När en header ställs in raderas alla befintliga värden för denna header, och ett nytt värde läggs till i slutet av listan över omslutna headers. Den befintliga ordningen på rubrikerna bibehålls i allmänhet, och nya rubriker läggs till i slutet av den omslutna listan.

Till skillnad från en ordbok ger Headers-objekt inte upphov till något fel när du försöker hämta eller ta bort en nyckel som inte finns i den omslutna headerlistan. Att hämta en icke-existerande header returnerar bara None, och att ta bort en icke-existerande header gör ingenting.

Headers-objekt stöder också metoderna keys(), values() och items(). Listorna som returneras av keys() och items() kan innehålla samma nyckel mer än en gång om det finns en header med flera värden. len() för ett Headers-objekt är samma som längden på dess items(), som är samma som längden på den omslutna header-listan. Faktum är att metoden items() bara returnerar en kopia av den omslutna header-listan.

Anrop av bytes() på ett Headers-objekt returnerar en formaterad bytestring som lämpar sig för överföring som HTTP-svarshuvuden. Varje header placeras på en rad med sitt värde, åtskilda av ett kolon och ett mellanslag. Varje rad avslutas med en vagnsretur och radmatning, och bytestringen avslutas med en blankrad.

Förutom mappningsgränssnittet och formateringsfunktionerna har Headers-objekten även följande metoder för att fråga efter och lägga till flervärdiga rubriker och för att lägga till rubriker med MIME-parametrar:

get_all(name)

Returnerar en lista med alla värden för den angivna rubriken.

Den returnerade listan kommer att sorteras i den ordning som de förekom i den ursprungliga huvudlistan eller lades till i denna instans, och kan innehålla dubbletter. Fält som tas bort och läggs till på nytt läggs alltid till i huvudlistan. Om det inte finns några fält med det angivna namnet returneras en tom lista.

add_header(name, value, **_params)

Lägg till ett (eventuellt flervärdigt) huvud med valfria MIME-parametrar som anges via nyckelordsargument.

name är rubrikfältet som ska läggas till. Keyword-argument kan användas för att ange MIME-parametrar för rubrikfältet. Varje parameter måste vara en sträng eller None. Underscores i parameternamn konverteras till bindestreck, eftersom bindestreck är olagliga i Python-identifierare, men många MIME-parameternamn innehåller bindestreck. Om parametervärdet är en sträng läggs det till i rubrikens värdeparametrar i formen name="value". Om det är None läggs endast parameternamnet till. (Detta används för MIME-parametrar utan värde.) Exempel på användning:

h.add_header('content-disposition', 'attachment', filnamn='bud.gif')

Ovanstående kommer att lägga till en rubrik som ser ut så här:

Innehåll-Disposition: attachment; filnamn="bud.gif"

Ändrad i version 3.5: parametern headers är valfri.

wsgiref.simple_server – en enkel WSGI HTTP-server

Denna modul implementerar en enkel HTTP-server (baserad på http.server) som betjänar WSGI-applikationer. Varje serverinstans betjänar en enda WSGI-applikation på en given värd och port. Om du vill betjäna flera program på en enda värd och port bör du skapa ett WSGI-program som analyserar PATH_INFO för att välja vilket program som ska anropas för varje begäran. (T.ex. med hjälp av funktionen shift_path_info() från wsgiref.util.)

wsgiref.simple_server.make_server(host, port, app, server_class=WSGIServer, handler_class=WSGIRequestHandler)

Skapa en ny WSGI-server som lyssnar på host och port och accepterar anslutningar för app. Returvärdet är en instans av den medföljande server_class, och kommer att behandla förfrågningar med hjälp av den angivna handler_class. app måste vara ett WSGI-applikationsobjekt, enligt definitionen i PEP 3333.

Exempel på användning:

from wsgiref.simple_server import make_server, demo_app

with make_server('', 8000, demo_app) as httpd:
    print("Serving HTTP on port 8000...")

    # Respond to requests until process is killed
    httpd.serve_forever()

    # Alternative: serve one request, then exit
    httpd.handle_request()
wsgiref.simple_server.demo_app(environ, start_response)

Denna funktion är en liten men komplett WSGI-applikation som returnerar en textsida som innehåller meddelandet ”Hello world!” och en lista över de nyckel/värde-par som anges i parametern environ. Den är användbar för att verifiera att en WSGI-server (t.ex. wsgiref.simple_server) kan köra en enkel WSGI-applikation korrekt.

Anropsbarheten start_response bör följa protokollet StartResponse.

class wsgiref.simple_server.WSGIServer(server_address, RequestHandlerClass)

Skapa en instans av WSGIServer. server_address ska vara en (host,port) tupel, och RequestHandlerClass ska vara underklassen till http.server.BaseHTTPRequestHandler som kommer att användas för att behandla förfrågningar.

Du behöver normalt inte anropa den här konstruktören, eftersom funktionen make_server() kan hantera alla detaljer åt dig.

WSGIServer är en underklass till http.server.HTTPServer, så alla dess metoder (som serve_forever() och handle_request()) är tillgängliga. WSGIServer tillhandahåller även dessa WSGI-specifika metoder:

set_app(application)

Ställer in den anropsbara application som den WSGI-applikation som ska ta emot förfrågningar.

get_app()

Returnerar den aktuella inställda applikationskallelsen.

Normalt behöver du dock inte använda dessa ytterligare metoder, eftersom set_app() normalt anropas av make_server(), och get_app() främst är till för request handler-instanser.

class wsgiref.simple_server.WSGIRequestHandler(request, client_address, server)

Skapa en HTTP-hanterare för den angivna request (dvs. en socket), client_address (en (host,port)-tupel) och server (WSGIServer-instans).

Du behöver inte skapa instanser av den här klassen direkt; de skapas automatiskt vid behov av WSGIServer-objekt. Du kan dock subklassa den här klassen och tillhandahålla den som en handler_class till funktionen make_server(). Några eventuellt relevanta metoder för åsidosättande i underklasser:

get_environ()

Returnerar en WSGIEnvironment-ordbok för en begäran. Standardimplementeringen kopierar innehållet i WSGIServer-objektets base_environ-ordboksattribut och lägger sedan till olika rubriker som härrör från HTTP-begäran. Varje anrop till denna metod bör returnera en ny dictionary som innehåller alla relevanta CGI-miljövariabler enligt specifikationen i PEP 3333.

get_stderr()

Returnerar det objekt som ska användas som wsgi.errors ström. Standardimplementeringen returnerar bara sys.stderr.

handle()

Behandlar HTTP-begäran. Standardimplementeringen skapar en hanterarinstans med hjälp av en wsgiref.handlers-klass för att implementera det faktiska WSGI-applikationsgränssnittet.

wsgiref.validate — WSGI-kontroll av överensstämmelse

När du skapar nya WSGI-applikationsobjekt, ramverk, servrar eller mellanprogram kan det vara användbart att validera den nya kodens överensstämmelse med wsgiref.validate. Denna modul tillhandahåller en funktion som skapar WSGI-applikationsobjekt som validerar kommunikation mellan en WSGI-server eller gateway och ett WSGI-applikationsobjekt, för att kontrollera båda sidors protokollkonformitet.

Observera att det här verktyget inte garanterar fullständig PEP 3333-kompatibilitet; om den här modulen inte ger några fel betyder det inte nödvändigtvis att det inte finns några fel. Men om den här modulen ger ett fel är det så gott som säkert att antingen servern eller programmet inte är 100% compliant.

Denna modul är baserad på paste.lint-modulen från Ian Bikings ”Python Paste”-bibliotek.

wsgiref.validate.validator(application)

Omslut applikation och returnera ett nytt WSGI-applikationsobjekt. Den returnerade applikationen kommer att vidarebefordra alla förfrågningar till den ursprungliga applikationen, och kommer att kontrollera att både applikationen och servern som anropar den överensstämmer med WSGI-specifikationen och RFC 2616.

Alla upptäckta avvikelser resulterar i att ett AssertionError uppstår; observera dock att hur dessa fel hanteras är serverberoende. Till exempel kommer wsgiref.simple_server och andra servrar baserade på wsgiref.handlers (som inte åsidosätter felhanteringsmetoderna för att göra något annat) helt enkelt att mata ut ett meddelande om att ett fel har inträffat och dumpa spårningen till sys.stderr eller någon annan felström.

Denna wrapper kan också generera utdata med modulen warnings för att indikera beteenden som kan ifrågasättas men som kanske inte egentligen är förbjudna av PEP 3333. Om de inte undertrycks med Pythons kommandoradsalternativ eller warnings API, kommer alla sådana varningar att skrivas till sys.stderr (inte wsgi.errors, såvida de inte råkar vara samma objekt).

Exempel på användning:

from wsgiref.validate import validator
from wsgiref.simple_server import make_server

# Our callable object which is intentionally not compliant to the
# standard, so the validator is going to break
def simple_app(environ, start_response):
    status = '200 OK'  # HTTP Status
    headers = [('Content-type', 'text/plain')]  # HTTP Headers
    start_response(status, headers)

    # This is going to break because we need to return a list, and
    # the validator is going to inform us
    return b"Hello World"

# This is the application wrapped in a validator
validator_app = validator(simple_app)

with make_server('', 8000, validator_app) as httpd:
    print("Listening on port 8000....")
    httpd.serve_forever()

wsgiref.handlers – basklasser för server/gateway

Den här modulen innehåller basklasser för hantering av WSGI-servrar och gateways. Dessa basklasser hanterar det mesta av arbetet med att kommunicera med en WSGI-applikation, så länge som de får en CGI-liknande miljö, tillsammans med inmatnings-, utmatnings- och felströmmar.

class wsgiref.handlers.CGIHandler

CGI-baserad anropning via sys.stdin, sys.stdout, sys.stderr och os.environ. Detta är användbart när du har en WSGI-applikation och vill köra den som ett CGI-skript. Anropa helt enkelt CGIHandler().run(app), där app är det WSGI-applikationsobjekt som du vill anropa.

Den här klassen är en underklass till BaseCGIHandler som sätter wsgi.run_once till true, wsgi.multithread till false och wsgi.multiprocess till true, och alltid använder sys och os för att få de nödvändiga CGI-strömmarna och miljön.

class wsgiref.handlers.IISCGIHandler

Ett specialiserat alternativ till CGIHandler, för användning vid distribution på Microsofts IIS-webbserver, utan att ha ställt in config allowPathInfo-alternativet (IIS>=7) eller metabasen allowPathInfoForScriptMappings (IIS<7).

Som standard ger IIS en PATH_INFO som duplicerar SCRIPT_NAME längst fram, vilket orsakar problem för WSGI-program som vill implementera routing. Denna hanterare tar bort alla sådana duplicerade sökvägar.

IIS kan konfigureras att skicka rätt PATH_INFO, men detta orsakar en annan bugg där PATH_TRANSLATED är fel. Lyckligtvis används den här variabeln sällan och garanteras inte av WSGI. På IIS<7 kan inställningen dock bara göras på vhost-nivå, vilket påverkar alla andra skriptmappningar, varav många går sönder när de utsätts för PATH_TRANSLATED-buggen. Av denna anledning distribueras IIS<7 nästan aldrig med korrigeringen (även IIS7 använder den sällan eftersom det fortfarande inte finns något användargränssnitt för den).

Det finns inget sätt för CGI-koden att avgöra om alternativet har ställts in, så en separat hanterarklass tillhandahålls. Den används på samma sätt som CGIHandler, d.v.s. genom att anropa IISCGIHandler().run(app), där app är det WSGI-applikationsobjekt som du vill anropa.

Tillagd i version 3.2.

class wsgiref.handlers.BaseCGIHandler(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)

Liknar CGIHandler, men istället för att använda modulerna sys och os anges CGI-miljön och I/O-strömmarna explicit. Värdena multithread och multiprocess används för att ange flaggorna wsgi.multithread och wsgi.multiprocess för alla program som körs av hanterarinstansen.

Denna klass är en subklass av SimpleHandler avsedd för användning med annan programvara än HTTP ”origin servers”. Om du skriver en implementering av ett gateway-protokoll (t.ex. CGI, FastCGI, SCGI, etc.) som använder en Status: header för att skicka en HTTP-status, vill du förmodligen underordna dig denna istället för SimpleHandler.

class wsgiref.handlers.SimpleHandler(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)

Liknar BaseCGIHandler, men är utformad för användning med HTTP-ursprungsmottagare. Om du skriver en HTTP-serverimplementation kommer du förmodligen att vilja underklassa denna istället för BaseCGIHandler.

Denna klass är en underklass till BaseHandler. Den åsidosätter metoderna __init__(), get_stdin(), get_stderr(), add_cgi_vars(), _write(), och _flush() för att stödja explicit inställning av miljö och strömmar via konstruktorn. Den miljö och de strömmar som anges lagras i attributen stdin, stdout, stderr och environ.

Metoden write() för stdout bör skriva varje del i sin helhet, som io.BufferedIOBase.

class wsgiref.handlers.BaseHandler

Detta är en abstrakt basklass för att köra WSGI-applikationer. Varje instans hanterar en enda HTTP-begäran, men i princip kan du skapa en underklass som kan återanvändas för flera begäranden.

BaseHandler-instanser har endast en metod avsedd för extern användning:

run(app)

Kör den angivna WSGI-applikationen, app.

Alla andra BaseHandler-metoder anropas av den här metoden när applikationen körs och finns därför främst till för att göra det möjligt att anpassa processen.

Följande metoder MÅSTE åsidosättas i en subklass:

_write(data)

Buffra byte data för överföring till klienten. Det är okej om den här metoden faktiskt överför data; BaseHandler separerar bara write och flush operationer för ökad effektivitet när det underliggande systemet faktiskt har en sådan distinktion.

_flush()

Tvinga buffrade data att överföras till klienten. Det är okej om den här metoden är en no-op (dvs. om _write() faktiskt skickar data).

get_stdin()

Returnerar ett objekt som är kompatibelt med InputStream och som kan användas som wsgi.input för den begäran som för närvarande behandlas.

get_stderr()

Returnerar ett objekt som är kompatibelt med ErrorStream och som kan användas som wsgi.errors för den begäran som för närvarande behandlas.

add_cgi_vars()

Infoga CGI-variabler för den aktuella begäran i attributet environ.

Här är några andra metoder och attribut som du kanske vill åsidosätta. Den här listan är dock bara en sammanfattning och innehåller inte alla metoder som kan åsidosättas. Du bör konsultera dokumentationen och källkoden för ytterligare information innan du försöker skapa en anpassad BaseHandler-underklass.

Attribut och metoder för att anpassa WSGI-miljön:

wsgi_multithread

Det värde som ska användas för miljövariabeln wsgi.multithread. Standardvärdet är true i BaseHandler, men kan ha ett annat standardvärde (eller ställas in av konstruktören) i de andra underklasserna.

wsgi_multiprocess

Det värde som ska användas för miljövariabeln wsgi.multiprocess. Standardvärdet är true i BaseHandler, men kan ha ett annat standardvärde (eller ställas in av konstruktören) i de andra underklasserna.

wsgi_run_once

Det värde som ska användas för miljövariabeln wsgi.run_once. Den är som standard false i BaseHandler, men CGIHandler sätter den till true som standard.

os_environ

Standardmiljövariablerna som ska inkluderas i varje begärandes WSGI-miljö. Som standard är detta en kopia av os.environ vid den tidpunkt då wsgiref.handlers importerades, men underklasser kan antingen skapa sina egna på klass- eller instansnivå. Observera att ordlistan bör betraktas som skrivskyddad, eftersom standardvärdet delas mellan flera klasser och instanser.

server_software

Om attributet origin_server är inställt, används detta attributs värde för att ställa in standard WSGI-miljövariabeln SERVER_SOFTWARE, och även för att ställa in en standard Server: header i HTTP-svar. Det ignoreras för hanterare (såsom BaseCGIHandler och CGIHandler) som inte är HTTP-ursprungsmottagare.

Ändrad i version 3.3: Termen ”Python” ersätts med implementationsspecifika termer som ”CPython”, ”Jython” etc.

get_scheme()

Returnerar det URL-schema som används för den aktuella begäran. Standardimplementeringen använder funktionen guess_scheme() från wsgiref.util för att gissa om schemat ska vara ”http” eller ”https”, baserat på den aktuella begärans environ-variabler.

setup_environ()

Ställ in attributet environ till en fullt ifylld WSGI-miljö. Standardimplementeringen använder alla ovanstående metoder och attribut, plus metoderna get_stdin(), get_stderr(), och add_cgi_vars() och attributet wsgi_file_wrapper. Den infogar också nyckeln SERVER_SOFTWARE om den inte finns, så länge attributet origin_server` är ett sant värde och attributet server_software` är angivet.

Metoder och attribut för att anpassa undantagshanteringen:

log_exception(exc_info)

Loggar exc_info-tupeln i serverloggen. exc_info är en (typ, värde, spårning) tupel. Standardimplementeringen skriver helt enkelt spårningen till begärandets wsgi.errors-ström och rensar den. Underklasser kan åsidosätta den här metoden för att ändra formatet eller rikta om utdata, skicka spårningen till en administratör eller någon annan åtgärd som kan anses lämplig.

traceback_limit

Det maximala antalet bildrutor som ska inkluderas i spårningar som matas ut av standardmetoden log_exception(). Om None inkluderas alla ramar.

error_output(environ, start_response)

Denna metod är en WSGI-applikation som genererar en felsida för användaren. Den anropas endast om ett fel inträffar innan rubrikerna skickas till klienten.

Den här metoden kan komma åt det aktuella felet med hjälp av sys.exception(), och bör skicka den informationen till start_response när den anropas (enligt beskrivningen i avsnittet ”Error Handling” i PEP 3333). I synnerhet bör den anropbara start_response följa StartResponse-protokollet.

Standardimplementeringen använder bara attributen error_status, error_headers och error_body för att generera en utdatasida. Subklasser kan åsidosätta detta för att producera mer dynamisk felutmatning.

Observera dock att det inte är rekommenderat ur ett säkerhetsperspektiv att spotta ut diagnostik till vilken användare som helst; helst bör du behöva göra något speciellt för att aktivera diagnostisk utmatning, vilket är anledningen till att standardimplementeringen inte innehåller någon.

error_status

Den HTTP-status som används för felsvar. Detta bör vara en statussträng enligt definitionen i PEP 3333; standardvärdet är en 500-kod och ett 500-meddelande.

error_headers

De HTTP-rubriker som används för felsvar. Detta bör vara en lista över WSGI-svarshuvuden ((namn, värde)-tupler), enligt beskrivningen i PEP 3333. Standardlistan sätter bara innehållstypen till text/plain.

error_body

Felmeddelandets brödtext. Detta bör vara en bytestring för HTTP-svarstext. Standardvärdet är klartext, ”Ett serverfel inträffade. Kontakta administratören.”

Metoder och attribut för PEP 3333:s funktion ”Optional Platform-Specific File Handling”:

wsgi_file_wrapper

En wsgi.file_wrapper-fabrik, kompatibel med wsgiref.types.FileWrapper, eller None. Standardvärdet för detta attribut är klassen wsgiref.util.FileWrapper.

sendfile()

Åsidosättande för att implementera plattformsspecifik filöverföring. Denna metod anropas endast om programmets returvärde är en instans av den klass som anges av attributet wsgi_file_wrapper. Den bör returnera ett sant värde om den lyckades överföra filen, så att standardöverföringskoden inte körs. Standardimplementeringen av denna metod returnerar bara ett falskt värde.

Diverse metoder och attribut:

origin_server

Detta attribut bör sättas till ett sant värde om hanterarens _write() och _flush() används för att kommunicera direkt till klienten, snarare än via ett CGI-liknande gateway-protokoll som vill ha HTTP-statusen i en speciell Status: header.

Detta attributs standardvärde är true i BaseHandler, men false i BaseCGIHandler och CGIHandler.

http_version

Om origin_server är true används detta strängattribut för att ange HTTP-versionen av det svar som skickas till klienten. Standardvärdet är "1.0".

wsgiref.handlers.read_environ()

Transcode CGI-variabler från os.environ till PEP 3333 ”bytes in unicode”-strängar, returnerar en ny ordbok. Denna funktion används av CGIHandler och IISCGIHandler i stället för att direkt använda os.environ, som inte nödvändigtvis är WSGI-kompatibel på alla plattformar och webbservrar som använder Python 3 – särskilt sådana där operativsystemets faktiska miljö är Unicode (dvs.windows), eller sådana där miljön är bytes, men systemkodningen som Python använder för att avkoda den är något annat än ISO-8859-1 (t.ex. Unix-system som använder UTF-8).

Om du implementerar en egen CGI-baserad hanterare vill du förmodligen använda den här rutinen i stället för att bara kopiera värden direkt från os.environ.

Tillagd i version 3.2.

wsgiref.types – WSGI-typer för statisk typkontroll

Denna modul tillhandahåller olika typer för statisk typkontroll enligt beskrivningen i PEP 3333.

Tillagd i version 3.11.

class wsgiref.types.StartResponse

En typing.Protocol som beskriver start_response() anropbara (PEP 3333).

wsgiref.types.WSGIEnvironment

Ett typalias som beskriver en WSGI-miljöordbok.

wsgiref.types.WSGIApplication

Ett typalias som beskriver en WSGI-applikation som kan anropas.

class wsgiref.types.InputStream

En typing.Protocol som beskriver en WSGI Input Stream.

class wsgiref.types.ErrorStream

En typing.Protocol som beskriver en WSGI Error Stream.

class wsgiref.types.FileWrapper

Ett typing.Protocol som beskriver en filomslag. Se wsgiref.util.FileWrapper för en konkret implementation av detta protokoll.

Exempel

Detta är en fungerande ”Hello World” WSGI applikation, där start_response callable ska följa StartResponse protokollet:

"""
Every WSGI application must have an application object - a callable
object that accepts two arguments. For that purpose, we're going to
use a function (note that you're not limited to a function, you can
use a class for example). The first argument passed to the function
is a dictionary containing CGI-style environment variables and the
second variable is the callable object.
"""
from wsgiref.simple_server import make_server


def hello_world_app(environ, start_response):
    status = "200 OK"  # HTTP Status
    headers = [("Content-type", "text/plain; charset=utf-8")]  # HTTP Headers
    start_response(status, headers)

    # The returned object is going to be printed
    return [b"Hello World"]

with make_server("", 8000, hello_world_app) as httpd:
    print("Serving on port 8000...")

    # Serve until process is killed
    httpd.serve_forever()

Exempel på en WSGI-applikation som betjänar den aktuella katalogen, acceptera valfri katalog och portnummer (standard: 8000) på kommandoraden:

"""
Small wsgiref based web server. Takes a path to serve from and an
optional port number (defaults to 8000), then tries to serve files.
MIME types are guessed from the file names, 404 errors are raised
if the file is not found.
"""
import mimetypes
import os
import sys
from wsgiref import simple_server, util


def app(environ, respond):
    # Get the file name and MIME type
    fn = os.path.join(path, environ["PATH_INFO"][1:])
    if "." not in fn.split(os.path.sep)[-1]:
        fn = os.path.join(fn, "index.html")
    mime_type = mimetypes.guess_file_type(fn)[0]

    # Return 200 OK if file exists, otherwise 404 Not Found
    if os.path.exists(fn):
        respond("200 OK", [("Content-Type", mime_type)])
        return util.FileWrapper(open(fn, "rb"))
    else:
        respond("404 Not Found", [("Content-Type", "text/plain")])
        return [b"not found"]


if __name__ == "__main__":
    # Get the path and port from command-line arguments
    path = sys.argv[1] if len(sys.argv) > 1 else os.getcwd()
    port = int(sys.argv[2]) if len(sys.argv) > 2 else 8000

    # Make and start the server until control-c
    httpd = simple_server.make_server("", port, app)
    print(f"Serving {path} on port {port}, control-C to stop")
    try:
        httpd.serve_forever()
    except KeyboardInterrupt:
        print("Shutting down.")
        httpd.server_close()