21.4. wsgiref — WSGIユーティリティとリファレンス実装—Pythonドキュメント
21.4。 wsgiref —WSGIユーティリティとリファレンス実装
Webサーバーゲートウェイインターフェイス(WSGI)は、Pythonで記述されたWebサーバーソフトウェアとWebアプリケーション間の標準インターフェイスです。 標準のインターフェイスを使用すると、さまざまなWebサーバーでWSGIをサポートするアプリケーションを簡単に使用できます。
WSGI設計のすべての詳細とコーナーケースを知る必要があるのは、Webサーバーとプログラミングフレームワークの作成者だけです。 WSGIアプリケーションをインストールしたり、既存のフレームワークを使用してWebアプリケーションを作成したりするためだけに、WSGIの詳細をすべて理解する必要はありません。
wsgiref は、WSGIサポートをWebサーバーまたはフレームワークに追加するために使用できるWSGI仕様のリファレンス実装です。 WSGI環境変数と応答ヘッダーを操作するためのユーティリティ、WSGIサーバーを実装するための基本クラス、WSGIアプリケーションを提供するデモHTTPサーバー、およびWSGIサーバーとアプリケーションがWSGI仕様に準拠しているかどうかを確認する検証ツールを提供します( [X293X ] PEP 3333 )。
WSGIの詳細、およびチュートリアルやその他のリソースへのリンクについては、 https://wsgi.readthedocs.org/を参照してください。
21.4.1。 wsgiref.util –WSGI環境ユーティリティ
このモジュールは、WSGI環境で作業するためのさまざまなユーティリティ機能を提供します。 WSGI環境は、 PEP 3333 で説明されているHTTPリクエスト変数を含むディクショナリです。 environ パラメーターを受け取るすべての関数は、WSGI準拠のディクショナリが提供されることを想定しています。 詳細な仕様については、 PEP 3333 を参照してください。
- wsgiref.util.guess_scheme(environ)
environment ディクショナリで
HTTPS
環境変数をチェックして、wsgi.url_scheme
が「http」または「https」のどちらであるかを推測します。 戻り値は文字列です。この関数は、CGIまたはFastCGIなどのCGIのようなプロトコルをラップするゲートウェイを作成するときに役立ちます。 通常、このようなプロトコルを提供するサーバーには、SSLを介して要求を受信したときに、値が「1」、「はい」、または「オン」の
HTTPS
変数が含まれます。 したがって、この関数は、そのような値が見つかった場合は「https」を返し、それ以外の場合は「http」を返します。
- wsgiref.util.request_uri(environ, include_query=True)
- PEP 3333 の「URLReconstruction」セクションにあるアルゴリズムを使用して、オプションでクエリ文字列を含む完全なリクエストURIを返します。 include_query がfalseの場合、クエリ文字列は結果のURIに含まれません。
- wsgiref.util.application_uri(environ)
- request_uri()と同様ですが、
PATH_INFO
変数とQUERY_STRING
変数が無視される点が異なります。 結果は、リクエストによってアドレス指定されたアプリケーションオブジェクトのベースURIです。
- wsgiref.util.shift_path_info(environ)
単一の名前を
PATH_INFO
からSCRIPT_NAME
にシフトし、名前を返します。 環境辞書は変更インプレースです。 元のPATH_INFO
またはSCRIPT_NAME
をそのまま維持する必要がある場合は、コピーを使用してください。PATH_INFO
にパスセグメントが残っていない場合は、None
が返されます。通常、このルーチンは、要求URIパスの各部分を処理するために使用されます。たとえば、パスを一連のディクショナリキーとして扱うために使用されます。 このルーチンは、渡された環境を変更して、ターゲットURIにある別のWSGIアプリケーションを呼び出すのに適したものにします。 たとえば、
/foo
にWSGIアプリケーションがあり、要求URIパスが/foo/bar/baz
であり、/foo
にあるWSGIアプリケーションが shift_path_info()[X162X ]、文字列「bar」を受け取り、/foo/bar
でWSGIアプリケーションに渡すのに適した環境に更新されます。 つまり、SCRIPT_NAME
は/foo
から/foo/bar
に変更され、PATH_INFO
は/bar/baz
から/baz
に変更されます。PATH_INFO
が単なる「/」の場合、空のパスセグメントは通常無視され、SCRIPT_NAME
は無視されますが、このルーチンは空の文字列を返し、末尾のスラッシュをSCRIPT_NAME
に追加します。通常、スラッシュで終わることはありません。 これは意図的な動作であり、このルーチンを使用してオブジェクトトラバーサルを実行するときに、アプリケーションが/x
で終わるURIと/x/
で終わるURIの違いを認識できるようにします。
- wsgiref.util.setup_testing_defaults(environ)
テスト目的で、 environ を簡単なデフォルトで更新します。
このルーチンは、
HTTP_HOST
、SERVER_NAME
、SERVER_PORT
、REQUEST_METHOD
、SCRIPT_NAME
、 [X125Xなど、WSGIに必要なさまざまなパラメーターを追加します。 ]、およびすべての PEP 3333 で定義されたwsgi.*
変数。 デフォルト値のみを提供し、これらの変数の既存の設定を置き換えることはありません。このルーチンは、WSGIサーバーとアプリケーションの単体テストでダミー環境を簡単にセットアップできるようにすることを目的としています。 データは偽物であるため、実際のWSGIサーバーやアプリケーションでは使用しないでください。
使用例:
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()
上記の環境機能に加えて、 wsgiref.util モジュールはこれらのその他のユーティリティも提供します。
- wsgiref.util.is_hop_by_hop(header_name)
- 'header_name'が RFC 2616 で定義されているように、HTTP /1.1の「Hop-by-Hop」ヘッダーである場合はtrueを返します。
- class wsgiref.util.FileWrapper(filelike, blksize=8192)
ファイルのようなオブジェクトをイテレータに変換するラッパー。 結果のオブジェクトは、Python 2.1およびJythonとの互換性のために、
__getitem__()
と__iter__()
の両方の反復スタイルをサポートします。 オブジェクトが繰り返されると、オプションの blksize パラメーターが filelike オブジェクトのread()
メソッドに繰り返し渡され、生成するバイト文字列が取得されます。read()
が空のバイト文字列を返すと、反復は終了し、再開できません。filelike に
close()
メソッドがある場合、返されるオブジェクトにもclose()
メソッドがあり、 filelike オブジェクトの [ X154X]呼び出されたときのメソッド。使用例:
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)
21.4.2。 wsgiref.headers –WSGI応答ヘッダーツール
このモジュールは、マッピングのようなインターフェイスを使用してWSGI応答ヘッダーを便利に操作するための単一のクラス Headers を提供します。
- class wsgiref.headers.Headers([headers])
headers をラップするマッピングのようなオブジェクトを作成します。これは、 PEP 3333 で説明されているヘッダー名/値タプルのリストである必要があります。 headers のデフォルト値は空のリストです。
ヘッダーオブジェクトは、
__getitem__()
、get()
、__setitem__()
、setdefault()
、__delitem__()
、__contains__()
。 これらの各メソッドの場合、キーはヘッダー名(大文字と小文字を区別せずに処理)であり、値はそのヘッダー名に関連付けられた最初の値です。 ヘッダーを設定すると、そのヘッダーの既存の値がすべて削除され、ラップされたヘッダーリストの最後に新しい値が追加されます。 ヘッダーの既存の順序は通常維持され、ラップされたリストの最後に新しいヘッダーが追加されます。辞書とは異なり、 Headers オブジェクトは、ラップされたヘッダーリストにないキーを取得または削除しようとしてもエラーを発生させません。 存在しないヘッダーを取得すると
None
が返されるだけで、存在しないヘッダーを削除しても何も起こりません。Headers オブジェクトは、
keys()
、values()
、およびitems()
メソッドもサポートします。keys()
およびitems()
によって返されるリストには、複数値のヘッダーがある場合、同じキーを複数回含めることができます。 Headers オブジェクトのlen()
は、そのitems()
の長さと同じであり、ラップされたヘッダーリストの長さと同じです。 実際、items()
メソッドは、ラップされたヘッダーリストのコピーを返すだけです。Headers オブジェクトで
bytes()
を呼び出すと、HTTP応答ヘッダーとしての送信に適したフォーマット済みのバイト文字列が返されます。 各ヘッダーは、コロンとスペースで区切られた値を持つ行に配置されます。 各行はキャリッジリターンとラインフィードで終了し、バイトストリングは空白行で終了します。Headers オブジェクトには、マッピングインターフェイスとフォーマット機能に加えて、複数値ヘッダーのクエリと追加、およびMIMEパラメーターを使用したヘッダーの追加のための次のメソッドもあります。
- get_all(name)
名前付きヘッダーのすべての値のリストを返します。
返されるリストは、元のヘッダーリストに表示された順序、またはこのインスタンスに追加された順序で並べ替えられ、重複する場合があります。 削除および再挿入されたフィールドは、常にヘッダーリストに追加されます。 指定された名前のフィールドが存在しない場合は、空のリストを返します。
- add_header(name, value, **_params)
キーワード引数を介して指定されたオプションのMIMEパラメーターを使用して、(場合によっては複数値の)ヘッダーを追加します。
name は、追加するヘッダーフィールドです。 キーワード引数を使用して、ヘッダーフィールドのMIMEパラメーターを設定できます。 各パラメータは文字列または
None
である必要があります。 Python識別子ではダッシュは無効であるため、パラメーター名のアンダースコアはダッシュに変換されますが、多くのMIMEパラメーター名にはダッシュが含まれています。 パラメータ値が文字列の場合、name="value"
の形式でヘッダー値パラメータに追加されます。None
の場合、パラメータ名のみが追加されます。 (これは、値のないMIMEパラメーターに使用されます。)使用例:h.add_header('content-disposition', 'attachment', filename='bud.gif')
上記は次のようなヘッダーを追加します:
Content-Disposition: attachment; filename="bud.gif"
バージョン3.5で変更: headers パラメーターはオプションです。
21.4.3。 wsgiref.simple_server –シンプルなWSGIHTTPサーバー
このモジュールは、WSGIアプリケーションにサービスを提供する単純なHTTPサーバー( http.server に基づく)を実装します。 各サーバーインスタンスは、特定のホストとポートで単一のWSGIアプリケーションを提供します。 1つのホストとポートで複数のアプリケーションを提供する場合は、PATH_INFO
を解析して、リクエストごとに呼び出すアプリケーションを選択するWSGIアプリケーションを作成する必要があります。 (たとえば、 wsgiref.util のshift_path_info()
関数を使用します。)
- wsgiref.simple_server.make_server(host, port, app, server_class=WSGIServer, handler_class=WSGIRequestHandler)
ホストとポートをリッスンし、アプリの接続を受け入れる新しいWSGIサーバーを作成します。 戻り値は、指定された server_class のインスタンスであり、指定された handler_class を使用してリクエストを処理します。 app は、 PEP 3333 で定義されているように、WSGIアプリケーションオブジェクトである必要があります。
使用例:
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)
- この関数は、「Hello world!」というメッセージを含むテキストページを返す、小さいながらも完全なWSGIアプリケーションです。 および environ パラメーターで提供されるキー/値ペアのリスト。 WSGIサーバー( wsgiref.simple_server など)が単純なWSGIアプリケーションを正しく実行できることを確認するのに役立ちます。
- class wsgiref.simple_server.WSGIServer(server_address, RequestHandlerClass)
WSGIServer インスタンスを作成します。 server_address は
(host,port)
タプルである必要があり、 RequestHandlerClass はリクエストの処理に使用される http.server.BaseHTTPRequestHandler のサブクラスである必要があります。make_server()関数がすべての詳細を処理できるため、通常はこのコンストラクターを呼び出す必要はありません。
WSGIServer は http.server.HTTPServer のサブクラスであるため、そのすべてのメソッド(
serve_forever()
やhandle_request()
など)を使用できます。 WSGIServer は、次のWSGI固有のメソッドも提供します。- set_app(application)
呼び出し可能なアプリケーションを、リクエストを受信するWSGIアプリケーションとして設定します。
- get_app()
現在設定されているアプリケーション呼び出し可能オブジェクトを返します。
ただし、通常、 set_app()は make_server()によって呼び出され、 get_app()が存在するため、これらの追加メソッドを使用する必要はありません。主にリクエストハンドラインスタンスの利益のために。
- class wsgiref.simple_server.WSGIRequestHandler(request, client_address, server)
指定されたリクエストのHTTPハンドラーを作成します(つまり、 ソケット)、 client_address (
(host,port)
タプル)、および server ( WSGIServer インスタンス)。このクラスのインスタンスを直接作成する必要はありません。 これらは、 WSGIServer オブジェクトによって必要に応じて自動的に作成されます。 ただし、このクラスをサブクラス化して、 handler_class として make_server()関数に提供することはできます。 サブクラスでオーバーライドするためのいくつかのおそらく関連するメソッド:
- get_environ()
リクエストのWSGI環境を含むディクショナリを返します。 デフォルトの実装では、 WSGIServer オブジェクトの
base_environ
ディクショナリ属性の内容がコピーされ、HTTPリクエストから派生したさまざまなヘッダーが追加されます。 このメソッドを呼び出すたびに、 PEP 3333 で指定されている関連するすべてのCGI環境変数を含む新しいディクショナリが返されます。
- get_stderr()
wsgi.errors
ストリームとして使用する必要があるオブジェクトを返します。 デフォルトの実装はsys.stderr
を返すだけです。
- handle()
HTTPリクエストを処理します。 デフォルトの実装では、 wsgiref.handlers クラスを使用してハンドラーインスタンスを作成し、実際のWSGIアプリケーションインターフェイスを実装します。
21.4.4。 wsgiref.validate —WSGI適合性チェッカー
新しいWSGIアプリケーションオブジェクト、フレームワーク、サーバー、またはミドルウェアを作成する場合、 wsgiref.validate を使用して新しいコードの適合性を検証すると便利な場合があります。 このモジュールは、WSGIサーバーまたはゲートウェイとWSGIアプリケーションオブジェクト間の通信を検証するWSGIアプリケーションオブジェクトを作成して、プロトコルの適合性について両側をチェックする機能を提供します。
このユーティリティは、 PEP 3333 への完全な準拠を保証するものではないことに注意してください。 このモジュールにエラーがないからといって、必ずしもエラーが存在しないとは限りません。 ただし、このモジュールでエラーが発生した場合は、サーバーまたはアプリケーションのいずれかが100 % cに準拠していないことはほぼ確実です。
このモジュールは、IanBickingの「PythonPaste」ライブラリのpaste.lint
モジュールに基づいています。
- wsgiref.validate.validator(application)
application をラップして、新しいWSGIアプリケーションオブジェクトを返します。 返されたアプリケーションは、すべての要求を元のアプリケーションに転送し、アプリケーションとそれを呼び出すサーバーの両方がWSGI仕様と に準拠していることを確認します。 RFC 2616 。
不適合が検出されると、 AssertionError が発生します。 ただし、これらのエラーの処理方法はサーバーに依存することに注意してください。 たとえば、 wsgiref.simple_server および wsgiref.handlers に基づく他のサーバー(他のことを行うためにエラー処理メソッドをオーバーライドしない)は、エラーが発生したというメッセージを出力するだけです。発生し、トレースバックを
sys.stderr
またはその他のエラーストリームにダンプします。このラッパーは、警告モジュールを使用して出力を生成し、疑わしいが PEP 3333 によって実際に禁止されていない動作を示す場合もあります。 Pythonコマンドラインオプションまたは warnings APIを使用して抑制されない限り、そのような警告は
sys.stderr
( notwsgi.errors
に書き込まれます。それらはたまたま同じオブジェクトです)。使用例:
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()
21.4.5。 wsgiref.handlers –サーバー/ゲートウェイの基本クラス
このモジュールは、WSGIサーバーとゲートウェイを実装するための基本ハンドラークラスを提供します。 これらの基本クラスは、入力、出力、およびエラーストリームとともに、CGIのような環境が与えられている限り、WSGIアプリケーションとの通信作業のほとんどを処理します。
- class wsgiref.handlers.CGIHandler
sys.stdin
、sys.stdout
、sys.stderr
、およびos.environ
を介したCGIベースの呼び出し。 これは、WSGIアプリケーションがあり、それをCGIスクリプトとして実行する場合に役立ちます。CGIHandler().run(app)
を呼び出すだけです。ここで、app
は、呼び出すWSGIアプリケーションオブジェクトです。このクラスは BaseCGIHandler のサブクラスであり、
wsgi.run_once
をtrue、wsgi.multithread
をfalse、wsgi.multiprocess
をtrueに設定し、常に sysを使用します。 および os を使用して、必要なCGIストリームと環境を取得します。
- class wsgiref.handlers.IISCGIHandler
に特化した代替手段 CGIHandler 、構成allowPathInfoオプション(IIS> = 7)またはメタベースallowPathInfoForScriptMappings(IIS <7)を設定せずに、MicrosoftのIISWebサーバーに展開するときに使用します。
デフォルトでは、IISは前面に
SCRIPT_NAME
を複製するPATH_INFO
を提供し、ルーティングを実装したいWSGIアプリケーションに問題を引き起こします。 このハンドラーは、そのような重複したパスを取り除きます。IISは、正しい
PATH_INFO
を渡すように構成できますが、これにより、PATH_TRANSLATED
が間違っているという別のバグが発生します。 幸い、この変数はめったに使用されず、WSGIによって保証されていません。 ただし、IIS <7では、設定は仮想ホストレベルでのみ行うことができ、他のすべてのスクリプトマッピングに影響します。これらのマッピングの多くは、PATH_TRANSLATED
バグ。 このため、IIS <7が修正プログラムとともに展開されることはほとんどありません。 (IIS7でさえ、UIがまだないため、ほとんど使用しません。)オプションが設定されているかどうかをCGIコードで判断する方法がないため、個別のハンドラークラスが提供されます。 これは、 CGIHandler と同じ方法で使用されます。つまり、
IISCGIHandler().run(app)
を呼び出すことによって使用されます。ここで、app
は呼び出すWSGIアプリケーションオブジェクトです。バージョン3.2の新機能。
- class wsgiref.handlers.BaseCGIHandler(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)
CGIHandler に似ていますが、 sys および os モジュールを使用する代わりに、CGI環境とI / Oストリームが明示的に指定されます。 multithread および multiprocess の値は、ハンドラーインスタンスによって実行されるアプリケーションの
wsgi.multithread
およびwsgi.multiprocess
フラグを設定するために使用されます。このクラスは、HTTP「オリジンサーバー」以外のソフトウェアでの使用を目的とした SimpleHandler のサブクラスです。
Status:
ヘッダーを使用してHTTPステータスを送信するゲートウェイプロトコル実装(CGI、FastCGI、SCGIなど)を作成している場合は、 SimpleHandler の代わりにこれをサブクラス化することをお勧めします。 ]。
- class wsgiref.handlers.SimpleHandler(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)
BaseCGIHandler に似ていますが、HTTPオリジンサーバーで使用するために設計されています。 HTTPサーバーの実装を作成している場合は、 BaseCGIHandler の代わりにこれをサブクラス化することをお勧めします。
このクラスは、 BaseHandler のサブクラスです。
__init__()
、get_stdin()
、get_stderr()
、add_cgi_vars()
、_write()
、および_flush()
メソッドをオーバーライドして、明示的な設定をサポートします。コンストラクターを介した環境とストリーム。 提供された環境とストリームは、stdin
、stdout
、stderr
、およびenviron
属性に格納されます。stdout の write()メソッドは、 io.BufferedIOBase のように、各チャンクを完全に書き込む必要があります。
- class wsgiref.handlers.BaseHandler
これは、WSGIアプリケーションを実行するための抽象基本クラスです。 各インスタンスは単一のHTTPリクエストを処理しますが、原則として、複数のリクエストに再利用可能なサブクラスを作成できます。
BaseHandler インスタンスには、外部使用を目的としたメソッドが1つだけあります。
- run(app)
指定されたWSGIアプリケーション app を実行します。
他のすべての BaseHandler メソッドは、アプリケーションの実行プロセスでこのメソッドによって呼び出されるため、主にプロセスのカスタマイズを可能にするために存在します。
次のメソッドは、サブクラスでオーバーライドする必要があります。
- _write(data)
クライアントに送信するためにバイトデータをバッファリングします。 このメソッドが実際にデータを送信しても問題ありません。 BaseHandler は、基礎となるシステムが実際にそのような区別を持っている場合に、効率を高めるために書き込み操作とフラッシュ操作を分離するだけです。
- _flush()
バッファリングされたデータを強制的にクライアントに送信します。 このメソッドがno-opである場合(つまり、 _write()が実際にデータを送信する場合)は問題ありません。
- get_stdin()
現在処理中のリクエストの
wsgi.input
として使用するのに適した入力ストリームオブジェクトを返します。
- get_stderr()
現在処理中のリクエストの
wsgi.errors
として使用するのに適した出力ストリームオブジェクトを返します。
- add_cgi_vars()
現在のリクエストのCGI変数を
environ
属性に挿入します。
オーバーライドしたい他のメソッドと属性を次に示します。 ただし、このリストは要約にすぎず、オーバーライドできるすべてのメソッドが含まれているわけではありません。 カスタマイズされた BaseHandler サブクラスを作成する前に、追加情報についてdocstringとソースコードを参照する必要があります。
WSGI環境をカスタマイズするための属性とメソッド:
- wsgi_multithread
wsgi.multithread
環境変数に使用される値。 BaseHandler ではデフォルトでtrueに設定されていますが、他のサブクラスではデフォルトが異なる(またはコンストラクターによって設定される)場合があります。
- wsgi_multiprocess
wsgi.multiprocess
環境変数に使用される値。 BaseHandler ではデフォルトでtrueに設定されていますが、他のサブクラスではデフォルトが異なる(またはコンストラクターによって設定される)場合があります。
- wsgi_run_once
wsgi.run_once
環境変数に使用される値。 BaseHandler ではデフォルトでfalseに設定されていますが、 CGIHandler ではデフォルトでtrueに設定されています。
- os_environ
すべてのリクエストのWSGI環境に含まれるデフォルトの環境変数。 デフォルトでは、これは wsgiref.handlers がインポートされたときの
os.environ
のコピーですが、サブクラスはクラスレベルまたはインスタンスレベルで独自に作成できます。 デフォルト値は複数のクラスとインスタンス間で共有されるため、ディクショナリは読み取り専用と見なす必要があることに注意してください。
- server_software
origin_server 属性が設定されている場合、この属性の値は、デフォルトの
SERVER_SOFTWARE
WSGI環境変数を設定するため、およびHTTP応答でデフォルトのServer:
ヘッダーを設定するために使用されます。 HTTPオリジンサーバーではないハンドラー( BaseCGIHandler や CGIHandler など)では無視されます。バージョン3.3で変更:「Python」という用語は、「CPython」、「Jython」などの実装固有の用語に置き換えられました。
- get_scheme()
現在のリクエストに使用されているURLスキームを返します。 デフォルトの実装では、 wsgiref.util の
guess_scheme()
関数を使用して、現在のリクエストのenviron
変数に基づいて、スキームを「http」にするか「https」にするかを推測します。
- setup_environ()
environ
属性を完全に実装されたWSGI環境に設定します。 デフォルトの実装では、上記のすべてのメソッドと属性に加えて、 get_stdin()、 get_stderr()、 add_cgi_vars()メソッドとが使用されます。 wsgi_file_wrapper 属性。 また、 origin_server 属性が真の値であり、 server_software 属性が設定されている限り、SERVER_SOFTWARE
キーが存在しない場合は挿入されます。
例外処理をカスタマイズするためのメソッドと属性:
- log_exception(exc_info)
exc_info タプルをサーバーログに記録します。 exc_info は
(type, value, traceback)
タプルです。 デフォルトの実装では、トレースバックをリクエストのwsgi.errors
ストリームに書き込んで、フラッシュします。 サブクラスは、このメソッドをオーバーライドして、形式を変更したり、出力を再ターゲットしたり、トレースバックを管理者にメールで送信したり、その他の適切と思われるアクションを実行したりできます。
- traceback_limit
デフォルトの log_exception()メソッドによって出力されるトレースバックに含めるフレームの最大数。
None
の場合、すべてのフレームが含まれます。
- error_output(environ, start_response)
このメソッドは、ユーザーのエラーページを生成するためのWSGIアプリケーションです。 ヘッダーがクライアントに送信される前にエラーが発生した場合にのみ呼び出されます。
このメソッドは、
sys.exc_info()
を使用して現在のエラー情報にアクセスでき、呼び出すときにその情報を start_response に渡す必要があります( [の「エラー処理」セクションで説明されています)。 X204X] PEP 3333 )。デフォルトの実装では、 error_status 、 error_headers 、および error_body 属性を使用して出力ページを生成します。 サブクラスはこれをオーバーライドして、より動的なエラー出力を生成できます。
ただし、セキュリティの観点から、古いユーザーに診断を吐き出すことはお勧めしません。 理想的には、診断出力を有効にするために何か特別なことをする必要があります。そのため、デフォルトの実装には何も含まれていません。
- error_status
エラー応答に使用されるHTTPステータス。 これは、 PEP 3333 で定義されているステータス文字列である必要があります。 デフォルトは500コードとメッセージです。
- error_headers
エラー応答に使用されるHTTPヘッダー。 これは、 PEP 3333 で説明されているように、WSGI応答ヘッダー(
(name, value)
タプル)のリストである必要があります。 デフォルトのリストでは、コンテンツタイプがtext/plain
に設定されているだけです。
- error_body
エラー応答本文。 これは、HTTP応答本文のバイト文字列である必要があります。 デフォルトでは、「サーバーエラーが発生しました。 管理者に連絡してください。」
PEP 3333 の「オプションのプラットフォーム固有のファイル処理」機能のメソッドと属性:
- wsgi_file_wrapper
wsgi.file_wrapper
ファクトリ、またはNone
。 この属性のデフォルト値は、 wsgiref.util.FileWrapper クラスです。
- sendfile()
プラットフォーム固有のファイル送信を実装するためにオーバーライドします。 このメソッドは、アプリケーションの戻り値が wsgi_file_wrapper 属性で指定されたクラスのインスタンスである場合にのみ呼び出されます。 ファイルを正常に送信できた場合はtrue値を返す必要があるため、デフォルトの送信コードは実行されません。 このメソッドのデフォルトの実装は、false値を返すだけです。
その他のメソッドと属性:
- origin_server
ハンドラーの _write()および _flush()を使用して、CGIのようなゲートウェイプロトコルを介さずにクライアントと直接通信する場合は、この属性をtrue値に設定する必要があります。特別な
Status:
ヘッダーにHTTPステータスが必要です。この属性のデフォルト値は、 BaseHandler ではtrueですが、 BaseCGIHandler および CGIHandler ではfalseです。
- http_version
origin_server がtrueの場合、この文字列属性は、クライアントに設定された応答のHTTPバージョンを設定するために使用されます。 デフォルトは
"1.0"
です。
- wsgiref.handlers.read_environ()
CGI変数を
os.environ
からPEP3333の「Unicodeのバイト」文字列にトランスコードし、新しい辞書を返します。 この関数は、os.environ
を直接使用する代わりに、 CGIHandler および IISCGIHandler によって使用されます。これは、Python3を使用するすべてのプラットフォームおよびWebサーバーで必ずしもWSGIに準拠しているとは限りません。 、OSの実際の環境がUnicodeであるもの(つまり Windows)、または環境がバイトであるが、Pythonがそれをデコードするために使用するシステムエンコーディングはISO-8859-1以外のものです(例: UTF-8を使用するUnixシステム)。独自のCGIベースのハンドラーを実装している場合は、
os.environ
から直接値をコピーするのではなく、このルーチンを使用することをお勧めします。バージョン3.2の新機能。
21.4.6。 例
これは、機能する「HelloWorld」WSGIアプリケーションです。
from wsgiref.simple_server import make_server
# 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 (see PEP 333).
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()