リクエストオブジェクトとレスポンスオブジェクト
クイック概要
Djangoは、リクエストオブジェクトとレスポンスオブジェクトを使用して、システムに状態を渡します。
ページがリクエストされると、Djangoはリクエストに関するメタデータを含む HttpRequest オブジェクトを作成します。 次に、Djangoは適切なビューをロードし、ビュー関数の最初の引数として HttpRequest を渡します。 各ビューは、 HttpResponse オブジェクトを返す責任があります。
このドキュメントでは、 django.http モジュールで定義されている HttpRequest および HttpResponse オブジェクトのAPIについて説明します。
HttpRequestオブジェクト
- class HttpRequest
属性
特に明記されていない限り、すべての属性は読み取り専用と見なす必要があります。
- HttpRequest.scheme
- リクエストのスキームを表す文字列(通常は
http
またはhttps
)。
- HttpRequest.body
バイト文字列としての生のHTTPリクエスト本文。 これは、従来のHTMLフォームとは異なる方法(バイナリイメージ、XMLペイロードなど)でデータを処理する場合に役立ちます。 従来のフォームデータを処理するには、 HttpRequest.POST を使用します。
HttpRequest.read()または HttpRequest.readline()を使用したファイルのようなインターフェイスを使用して、
HttpRequest
から読み取ることもできます。 これらのI / Oストリームメソッドのいずれかを使用してリクエストを読み取った後にbody
属性にアクセスすると、RawPostDataException
が生成されます。
- HttpRequest.path
スキーム、ドメイン、またはクエリ文字列を含まない、要求されたページへのフルパスを表す文字列。
例:
"/music/bands/the_beatles/"
- HttpRequest.path_info
一部のWebサーバー構成では、ホスト名の後のURLの部分が、スクリプトプレフィックス部分とパス情報部分に分割されます。
path_info
属性には、使用されているWebサーバーに関係なく、常にパスのパス情報部分が含まれます。 path の代わりにこれを使用すると、テストサーバーとデプロイメントサーバー間でコードを簡単に移動できます。たとえば、アプリケーションの
WSGIScriptAlias
が"/minfo"
に設定されている場合、path
は"/minfo/music/bands/the_beatles/"
になり、path_info
は"/music/bands/the_beatles/"
。
- HttpRequest.method
リクエストで使用されるHTTPメソッドを表す文字列。 これは大文字であることが保証されています。 例えば:
- HttpRequest.encoding
- フォーム送信データのデコードに使用される現在のエンコーディングを表す文字列(または
None
、つまり:setting: `DEFAULT_CHARSET` 設定が使用されます)。 この属性に書き込むと、フォームデータにアクセスするときに使用されるエンコーディングを変更できます。 以降の属性アクセス( GET または POST からの読み取りなど)では、新しいencoding
値が使用されます。 フォームデータが:setting: `DEFAULT_CHARSET` エンコーディングではないことがわかっている場合に便利です。
- HttpRequest.content_type
CONTENT_TYPE
ヘッダーから解析された、リクエストのMIMEタイプを表す文字列。
- HttpRequest.content_params
CONTENT_TYPE
ヘッダーに含まれるキー/値パラメーターの辞書。
- HttpRequest.GET
- 指定されたすべてのHTTPGETパラメータを含む辞書のようなオブジェクト。 以下の QueryDict のドキュメントを参照してください。
- HttpRequest.POST
リクエストにフォームデータが含まれている場合、指定されたすべてのHTTPPOSTパラメータを含む辞書のようなオブジェクト。 以下の QueryDict のドキュメントを参照してください。 リクエストに投稿された生データまたは非フォームデータにアクセスする必要がある場合は、代わりに HttpRequest.body 属性を使用してアクセスしてください。
空の
POST
ディクショナリを使用してPOST経由でリクエストを受信できる可能性があります。たとえば、フォームがPOST HTTPメソッド経由でリクエストされたが、フォームデータが含まれていない場合です。 したがって、if request.POST
を使用してPOSTメソッドの使用を確認しないでください。 代わりに、if request.method == "POST"
を使用してください( HttpRequest.method を参照)。POST
にはファイルアップロード情報が含まれていません。 ファイルを参照してください。
- HttpRequest.COOKIES
- すべてのCookieを含む辞書。 キーと値は文字列です。
- HttpRequest.FILES
アップロードされたすべてのファイルを含む辞書のようなオブジェクト。
FILES
の各キーは、<input type="file" name="">
のname
です。FILES
の各値は UploadedFile です。詳細については、ファイルの管理を参照してください。
FILES
には、リクエストメソッドがPOSTであり、リクエストに投稿された<form>
にenctype="multipart/form-data"
が含まれている場合にのみデータが含まれます。 それ以外の場合、FILES
は空白の辞書のようなオブジェクトになります。
- HttpRequest.META
使用可能なすべてのHTTPヘッダーを含む辞書。 使用可能なヘッダーはクライアントとサーバーによって異なりますが、次にいくつかの例を示します。
CONTENT_LENGTH
–リクエスト本文の長さ(文字列として)。CONTENT_TYPE
–リクエスト本文のMIMEタイプ。HTTP_ACCEPT
–応答に使用できるコンテンツタイプ。HTTP_ACCEPT_ENCODING
–応答に使用できるエンコーディング。HTTP_ACCEPT_LANGUAGE
–応答に使用できる言語。HTTP_HOST
–クライアントから送信されたHTTPホストヘッダー。HTTP_REFERER
–参照ページ(ある場合)。HTTP_USER_AGENT
–クライアントのユーザーエージェント文字列。QUERY_STRING
–単一の(解析されていない)文字列としてのクエリ文字列。REMOTE_ADDR
–クライアントのIPアドレス。REMOTE_HOST
–クライアントのホスト名。REMOTE_USER
– Webサーバーによって認証されたユーザー(存在する場合)。REQUEST_METHOD
–"GET"
や"POST"
などの文字列。SERVER_NAME
–サーバーのホスト名。SERVER_PORT
–サーバーのポート(文字列として)。
CONTENT_LENGTH
とCONTENT_TYPE
を除いて、上記のように、リクエスト内のHTTPヘッダーは、すべての文字を大文字に変換し、ハイフンをアンダースコアに置き換えることで、META
キーに変換されます。名前にHTTP_
プレフィックスを追加します。 したがって、たとえば、X-Bender
というヘッダーはMETA
キーHTTP_X_BENDER
にマップされます。:djadmin: `runserver` は、名前にアンダースコアが含まれるすべてのヘッダーを削除するため、
META
には表示されないことに注意してください。 これにより、アンダースコアとダッシュのあいまいさに基づくヘッダースプーフィングが、WSGI環境変数のアンダースコアに正規化されるのを防ぎます。 これは、NginxやApache2.4以降などのWebサーバーの動作と一致します。HttpRequest.headers は、すべてのHTTPプレフィックスヘッダーに加えて、
CONTENT_LENGTH
とCONTENT_TYPE
にアクセスするためのより簡単な方法です。
- HttpRequest.headers
大文字と小文字を区別せず、リクエストからすべてのHTTPプレフィックスヘッダー(および
Content-Length
とContent-Type
)へのアクセスを提供するdictのようなオブジェクト。各ヘッダーの名前は、タイトルケースで様式化されています(例:
User-Agent
)が表示されたとき。 大文字と小文字を区別せずにヘッダーにアクセスできます。たとえば、Djangoテンプレートで使用する場合、ヘッダーはハイフンの代わりにアンダースコアを使用して検索することもできます。
- HttpRequest.resolver_match
- 解決されたURLを表す ResolverMatch のインスタンス。 この属性は、URL解決が行われた後にのみ設定されます。つまり、URL解決が行われる前に実行されるミドルウェアではなく、すべてのビューで使用できます(ただし、 process_view()で使用できます)。
アプリケーションコードによって設定された属性
Djangoはこれらの属性自体を設定しませんが、アプリケーションによって設定された場合はそれらを利用します。
- HttpRequest.current_app
- :ttag: `url` テンプレートタグは、その値を reverse()の
current_app
引数として使用します。
- HttpRequest.urlconf
これは、現在のリクエストのルートURLconfとして使用され、:setting: `ROOT_URLCONF` 設定を上書きします。 詳細については、 Djangoがリクエストを処理する方法を参照してください。
urlconf
をNone
に設定すると、以前のミドルウェアによって行われた変更を元に戻し、:setting: `ROOT_URLCONF` の使用に戻ることができます。
- HttpRequest.exception_reporter_filter
- これは、現在のリクエストで:setting: `DEFAULT_EXCEPTION_REPORTER_FILTER` の代わりに使用されます。 詳細については、カスタムエラーレポートを参照してください。
- HttpRequest.exception_reporter_class
- これは、現在のリクエストで:setting: `DEFAULT_EXCEPTION_REPORTER` の代わりに使用されます。 詳細については、カスタムエラーレポートを参照してください。
ミドルウェアによって設定された属性
Djangoのcontribアプリに含まれているミドルウェアの一部は、リクエストに応じて属性を設定します。 リクエストに属性が表示されない場合は、適切なミドルウェアクラスが:setting: `MIDDLEWARE` にリストされていることを確認してください。
- HttpRequest.session
- SessionMiddleware から:現在のセッションを表す、読み取りおよび書き込み可能な辞書のようなオブジェクト。
- HttpRequest.site
- CurrentSiteMiddleware から:現在のサイトを表す get_current_site()によって返される Site または RequestSite のインスタンス。
- HttpRequest.user
AuthenticationMiddleware から:現在ログインしているユーザーを表す:setting: `AUTH_USER_MODEL` のインスタンス。 ユーザーが現在ログインしていない場合、
user
は AnonymousUser のインスタンスに設定されます。 次のように、 is_authenticated でそれらを区別できます。
メソッド
- HttpRequest.get_host()
HTTP_X_FORWARDED_HOST
(:setting: `USE_X_FORWARDED_HOST` が有効な場合)およびHTTP_HOST
ヘッダーからの情報を使用して、リクエストの発信元ホストをこの順序で返します。 値が提供されない場合、このメソッドは、 PEP 3333 で詳しく説明されているように、SERVER_NAME
とSERVER_PORT
の組み合わせを使用します。例:
"127.0.0.1:8000"
ホストが:setting: `ALLOWED_HOSTS` にない場合、または RFC 1034 / に従ってドメイン名が無効な場合、
django.core.exceptions.DisallowedHost
を発生させます] 1035 。ノート
get_host()メソッドは、ホストが複数のプロキシの背後にある場合に失敗します。 1つの解決策は、次の例のように、ミドルウェアを使用してプロキシヘッダーを書き換えることです。
このミドルウェアは、 get_host()の値に依存する他のミドルウェア(たとえば、 CommonMiddleware または CsrfViewMiddleware )の前に配置する必要があります。
- HttpRequest.get_port()
HTTP_X_FORWARDED_PORT
(:setting: `USE_X_FORWARDED_PORT` が有効になっている場合)およびSERVER_PORT
META
変数からの情報を使用して、リクエストの発信元ポートを返します。その順序。
- HttpRequest.get_full_path()
path
に加えて、該当する場合は追加されたクエリ文字列を返します。例:
"/music/bands/the_beatles/?print=true"
- HttpRequest.get_full_path_info()
get_full_path()と同様ですが、 path の代わりに path_info を使用します。
例:
"/minfo/music/bands/the_beatles/?print=true"
- HttpRequest.build_absolute_uri(location=None)
location
の絶対URI形式を返します。 場所が指定されていない場合、場所はrequest.get_full_path()
に設定されます。場所がすでに絶対URIである場合、変更されません。 それ以外の場合、絶対URIは、このリクエストで使用可能なサーバー変数を使用して構築されます。 例えば:
ノート
同じサイトでHTTPとHTTPSを混在させることはお勧めしません。したがって、 build_absolute_uri()は、現在のリクエストと同じスキームで常に絶対URIを生成します。 ユーザーをHTTPSにリダイレクトする必要がある場合は、WebサーバーにすべてのHTTPトラフィックをHTTPSにリダイレクトさせるのが最善です。
- HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt=, max_age=None)
署名されたCookieのCookie値を返すか、署名が無効になった場合は
django.core.signing.BadSignature
例外を発生させます。default
引数を指定すると、例外が抑制され、代わりにそのデフォルト値が返されます。オプションの
salt
引数を使用すると、秘密鍵に対するブルートフォース攻撃に対する保護を強化できます。 指定した場合、max_age
引数は、Cookieがmax_age
秒より古くないことを確認するために、Cookie値に添付された署名付きタイムスタンプと照合されます。例えば:
詳細については、暗号署名を参照してください。
- HttpRequest.is_secure()
- リクエストが安全な場合は
True
を返します。 つまり、HTTPSで作成された場合です。
- HttpRequest.accepts(mime_type)
バージョン3.1の新機能。
リクエスト
Accept
ヘッダーがmime_type
引数と一致する場合、True
を返します。ほとんどのブラウザはデフォルトで
Accept: */*
を送信するため、すべてのコンテンツタイプに対してTrue
が返されます。 APIリクエストで明示的なAccept
ヘッダーを設定すると、それらのコンシューマーに対してのみ異なるコンテンツタイプを返す場合に役立ちます。accepts()
を使用してさまざまなコンテンツをAPIコンシューマーに返すコンテンツネゴシエーションの例を参照してください。Accept
ヘッダーの内容によって応答が異なり、Djangoのキャッシュミドルウェアなどのキャッシュを使用している場合は、ビューを vary_on_headers(')で装飾する必要があります。 Accept ')を実行して、応答が適切にキャッシュされるようにします。
- HttpRequest.is_ajax()
バージョン3.1以降非推奨。
文字列
'XMLHttpRequest'
のHTTP_X_REQUESTED_WITH
ヘッダーをチェックして、XMLHttpRequest
を介して要求が行われた場合、True
を返します。 最新のJavaScriptライブラリのほとんどは、このヘッダーを送信します。 独自のXMLHttpRequest
呼び出しを(ブラウザー側で)作成する場合、is_ajax()
を機能させるには、このヘッダーを手動で設定する必要があります。AJAXを介して要求されたかどうかによって応答が異なり、Djangoのキャッシュミドルウェアのような何らかの形式のキャッシュを使用している場合は、ビューを vary_on_headers(' X-Requested-With)で装飾する必要があります。 ')。これにより、応答が適切にキャッシュされます。
- HttpRequest.read(size=None)
- HttpRequest.readline()
- HttpRequest.readlines()
- HttpRequest.__iter__()
HttpRequest
インスタンスから読み取るためのファイルのようなインターフェイスを実装するメソッド。 これにより、着信要求をストリーミング方式で消費することが可能になります。 一般的な使用例は、メモリ内にXMLツリー全体を構築せずに、反復パーサーを使用して大きなXMLペイロードを処理することです。この標準インターフェースを指定すると、
HttpRequest
インスタンスをElementTree
などのXMLパーサーに直接渡すことができます。
QueryDictオブジェクト
- class QueryDict
HttpRequest オブジェクトでは、 GET および POST 属性は、django.http.QueryDict
のインスタンスです。これは、複数の値を処理するようにカスタマイズされた辞書のようなクラスです。同じキー。 一部のHTMLフォーム要素(特に<select multiple>
)は、同じキーに複数の値を渡すため、これが必要です。
request.POST
およびrequest.GET
のQueryDict
は、通常の要求/応答サイクルでアクセスすると不変になります。 変更可能なバージョンを取得するには、 QueryDict.copy()を使用する必要があります。
メソッド
QueryDict は、ディクショナリのサブクラスであるため、すべての標準ディクショナリメソッドを実装します。 例外の概要は次のとおりです。
- QueryDict.__init__(query_string=None, mutable=False, encoding=None)
query_string
に基づいてQueryDict
オブジェクトをインスタンス化します。query_string
が渡されない場合、結果のQueryDict
は空になります(キーまたは値はありません)。遭遇するほとんどの
QueryDict
、特にrequest.POST
とrequest.GET
のものは不変です。 自分でインスタンス化する場合は、mutable=True
を__init__()
に渡すことで変更可能にすることができます。キーと値の両方を設定するための文字列は、
encoding
からstr
に変換されます。encoding
が設定されていない場合、デフォルトで:setting: `DEFAULT_CHARSET` になります。
- classmethod QueryDict.fromkeys(iterable, value=, mutable=False, encoding=None)
iterable
のキーを使用し、各値がvalue
に等しい、新しいQueryDict
を作成します。 例えば:
- QueryDict.__getitem__(key)
- 指定されたキーの値を返します。 キーに複数の値がある場合は、最後の値を返します。 キーが存在しない場合は
django.utils.datastructures.MultiValueDictKeyError
を発生させます。 (これはPythonの標準KeyError
のサブクラスであるため、KeyError
のキャッチに固執することができます。)
- QueryDict.__setitem__(key, value)
- 指定されたキーを
[value]
(単一要素がvalue
であるリスト)に設定します。 これは、副作用のある他の辞書関数と同様に、変更可能なQueryDict
( QueryDict.copy()を介して作成されたものなど)でのみ呼び出すことができることに注意してください。
- QueryDict.__contains__(key)
- 指定されたキーが設定されている場合、
True
を返します。 これにより、たとえばif "foo" in request.GET
を実行できます。
- QueryDict.get(key, default=None)
- __ getitem __()と同じロジックを使用し、キーが存在しない場合にデフォルト値を返すためのフックを使用します。
- QueryDict.setdefault(key, default=None)
dict.setdefault()
と同様ですが、内部で __ setitem __()を使用する点が異なります。
- QueryDict.update(other_dict)
QueryDict
または辞書のいずれかを取ります。dict.update()
と同様ですが、現在の辞書アイテムを置き換えるのではなく、がに追加する点が異なります。 例えば:
- QueryDict.items()
dict.items()
と同様ですが、これは __ getitem __()と同じ最終値ロジックを使用し、ビューオブジェクトの代わりにイテレータオブジェクトを返します。 例えば:
- QueryDict.values()
dict.values()
と同様ですが、これは __ getitem __()と同じ最終値ロジックを使用し、ビューオブジェクトの代わりにイテレーターを返します。 例えば:
さらに、QueryDict
には次のメソッドがあります。
- QueryDict.copy()
copy.deepcopy()
を使用してオブジェクトのコピーを返します。 このコピーは、元のコピーが変更可能でなかった場合でも変更可能です。
- QueryDict.getlist(key, default=None)
- 要求されたキーを持つデータのリストを返します。 キーが存在せず、
default
がNone
の場合、空のリストを返します。 提供されるデフォルト値がリストでない限り、リストを返すことが保証されています。
- QueryDict.setlist(key, list_)
- 指定されたキーを
list_
に設定します( __ setitem __()とは異なります)。
- QueryDict.appendlist(key, item)
- キーに関連付けられた内部リストにアイテムを追加します。
- QueryDict.setlistdefault(key, default_list=None)
- setdefault()と同様ですが、単一の値ではなく値のリストを取得する点が異なります。
- QueryDict.lists()
items()と同様ですが、ディクショナリの各メンバーのすべての値がリストとして含まれている点が異なります。 例えば:
- QueryDict.pop(key)
指定されたキーの値のリストを返し、それらをディクショナリから削除します。 キーが存在しない場合は
KeyError
を発生させます。 例えば:
- QueryDict.popitem()
ディクショナリの任意のメンバーを削除し(順序付けの概念がないため)、キーを含む2つの値のタプルと、キーのすべての値のリストを返します。 空の辞書で呼び出されると、
KeyError
が発生します。 例えば:
- QueryDict.dict()
QueryDict
のdict
表現を返します。QueryDict
のすべての(key、list)ペアに対して、dict
には(key、item)があります。ここで、itemは、 QueryDict .__ getitem__と同じロジックを使用して、リストの1つの要素です。 ():
- QueryDict.urlencode(safe=None)
データの文字列をクエリ文字列形式で返します。 例えば:
safe
パラメーターを使用して、エンコードを必要としない文字を渡します。 例えば:
HttpResponseオブジェクト
- class HttpResponse
Djangoによって自動的に作成される HttpRequest オブジェクトとは対照的に、 HttpResponse オブジェクトはユーザーの責任です。 作成する各ビューは、 HttpResponse のインスタンス化、入力、および返送を担当します。
HttpResponse クラスは django.http モジュールにあります。
使用法
文字列を渡す
一般的な使用法は、ページのコンテンツを文字列、バイト文字列、またはmemoryview
として HttpResponse コンストラクターに渡すことです。
ただし、コンテンツを段階的に追加する場合は、response
をファイルのようなオブジェクトとして使用できます。
イテレータの受け渡し
最後に、文字列ではなくHttpResponse
イテレータを渡すことができます。 HttpResponse
はイテレータをすぐに消費し、その内容を文字列として保存して破棄します。 ファイルやジェネレーターなど、close()
メソッドを持つオブジェクトはすぐに閉じられます。
イテレータからクライアントに応答をストリーミングする必要がある場合は、代わりに StreamingHttpResponse クラスを使用する必要があります。
ヘッダーフィールドの設定
応答のヘッダーフィールドを設定または削除するには、 HttpResponse.headers を使用します。
応答を辞書のように扱うことで、ヘッダーを操作することもできます。
これはHttpResponse.headers
のプロキシであり、HttpResponse
によって提供される元のインターフェイスです。
このインターフェイスを使用する場合、辞書とは異なり、ヘッダーフィールドが存在しない場合、del
はKeyError
を発生させません。
インスタンス化時にヘッダーを設定することもできます。
Cache-Control
およびVary
ヘッダーフィールドを設定するには、 djangoの patch_cache_control()および patch_vary_headers()メソッドを使用することをお勧めします.utils.cache 、これらのフィールドは複数のコンマ区切り値を持つことができるため。 「パッチ」メソッドは、他の値を保証します。 ミドルウェアによって追加されたものは削除されません。
HTTPヘッダーフィールドに改行を含めることはできません。 改行文字(CRまたはLF)を含むヘッダーフィールドを設定しようとすると、BadHeaderError
が発生します。
応答を添付ファイルとして扱うようにブラウザに指示する
応答を添付ファイルとして扱うようにブラウザに指示するには、Content-Type
およびContent-Disposition
ヘッダーを設定します。 たとえば、MicrosoftExcelスプレッドシートを返す方法は次のとおりです。
Content-Disposition
ヘッダーについては、Django固有のものは何もありませんが、構文を忘れがちなので、ここに含めました。
属性
- HttpResponse.content
- 必要に応じて文字列からエンコードされた、コンテンツを表すバイト文字列。
- HttpResponse.headers
バージョン3.2の新機能。
大文字と小文字を区別しない、dictのようなオブジェクトで、応答のすべてのHTTPヘッダーへのインターフェイスを提供します。 ヘッダーフィールドの設定を参照してください。
- HttpResponse.charset
- 応答がエンコードされる文字セットを示す文字列。
HttpResponse
のインスタンス化時に指定されていない場合は、content_type
から抽出され、それが失敗した場合は、:setting: `DEFAULT_CHARSET` 設定が使用されます。
- HttpResponse.status_code
応答の HTTPステータスコード。
reason_phrase が明示的に設定されていない限り、コンストラクターの外部で
status_code
の値を変更すると、reason_phrase
の値も変更されます。
- HttpResponse.reason_phrase
応答のHTTP理由句。 HTTP標準のデフォルトの理由フレーズを使用します。
明示的に設定されていない限り、
reason_phrase
は status_code の値によって決定されます。
- HttpResponse.streaming
これは常に
False
です。この属性が存在するため、ミドルウェアはストリーミング応答を通常の応答とは異なる方法で処理できます。
- HttpResponse.closed
True
応答が閉じられている場合。
メソッド
- HttpResponse.__init__(content=b, content_type=None, status=200, reason=None, charset=None, headers=None)
指定されたページコンテンツ、コンテンツタイプ、およびヘッダーを使用して
HttpResponse
オブジェクトをインスタンス化します。content
は、最も一般的にはイテレータ、バイト文字列、memoryview
、または文字列です。 他のタイプは、文字列表現をエンコードすることによってバイト文字列に変換されます。 イテレータは文字列またはバイト文字列を返す必要があり、それらは結合されて応答のコンテンツを形成します。content_type
は、オプションで文字セットエンコーディングによって補完されるMIMEタイプであり、HTTPContent-Type
ヘッダーを埋めるために使用されます。 指定しない場合は、'text/html'
と:setting: `DEFAULT_CHARSET` の設定(デフォルトでは"text/html; charset=utf-8"
)で構成されます。status
は、応答の HTTPステータスコードです。HTTPStatus.NO_CONTENT
などの意味のあるエイリアスには、Pythonのhttp.HTTPStatus
を使用できます。reason
はHTTP応答フレーズです。 指定しない場合、デフォルトのフレーズが使用されます。charset
は、応答がエンコードされる文字セットです。 指定しない場合はcontent_type
から抽出され、失敗した場合は:setting: `DEFAULT_CHARSET` 設定が使用されます。headers
は、応答のHTTPヘッダーのdict
です。バージョン3.2で変更:
headers
パラメーターが追加されました。
- HttpResponse.__setitem__(header, value)
- 指定されたヘッダー名を指定された値に設定します。
header
とvalue
はどちらも文字列である必要があります。
- HttpResponse.__delitem__(header)
- 指定された名前のヘッダーを削除します。 ヘッダーが存在しない場合、サイレントに失敗します。 大文字小文字を区別しません。
- HttpResponse.__getitem__(header)
- 指定されたヘッダー名の値を返します。 大文字小文字を区別しません。
- HttpResponse.get(header, alternate=None)
- 指定されたヘッダーの値を返します。ヘッダーが存在しない場合は
alternate
を返します。
- HttpResponse.has_header(header)
- 指定された名前のヘッダーの大文字と小文字を区別しないチェックに基づいて、
True
またはFalse
を返します。
- HttpResponse.items()
- 応答のHTTPヘッダーに対して
dict.items()
のように機能します。
- HttpResponse.setdefault(header, value)
- すでに設定されていない限り、ヘッダーを設定します。
- HttpResponse.set_cookie(key, value=, max_age=None, expires=None, path='/', domain=None, secure=False, httponly=False, samesite=None)
クッキーを設定します。 パラメータは、Python標準ライブラリの
Morsel
cookieオブジェクトと同じです。max_age
は整数の秒数である必要があり、Cookieがクライアントのブラウザセッションの間だけ持続する必要がある場合はNone
(デフォルト)である必要があります。expires
が指定されていない場合は、計算されます。expires
は、"Wdy, DD-Mon-YY HH:MM:SS GMT"
形式の文字列またはUTCのdatetime.datetime
オブジェクトのいずれかである必要があります。expires
がdatetime
オブジェクトの場合、max_age
が計算されます。クロスドメインCookieを設定する場合は、
domain
を使用してください。 たとえば、domain="example.com"
は、ドメインwww.example.com、blog.example.comなどで読み取り可能なCookieを設定します。 それ以外の場合、Cookieはそれを設定したドメインによってのみ読み取り可能になります。https
スキームでリクエストが行われた場合にのみ、Cookieをサーバーに送信する場合は、secure=True
を使用します。クライアント側のJavaScriptがCookieにアクセスできないようにする場合は、
httponly=True
を使用します。HttpOnly は、Set-CookieHTTP応答ヘッダーに含まれるフラグです。 これはCookieの RFC 6265 標準の一部であり、クライアント側のスクリプトが保護されたCookieデータにアクセスするリスクを軽減するための便利な方法です。
samesite='Strict'
またはsamesite='Lax'
を使用して、クロスオリジンリクエストを実行するときにこのCookieを送信しないようにブラウザに指示します。 SameSite はすべてのブラウザーでサポートされているわけではないため、DjangoのCSRF保護に代わるものではなく、多層防御手段です。samesite='None'
(文字列)を使用して、このCookieがすべての同じサイトおよびクロスサイトリクエストで送信されることを明示的に示します。
バージョン3.1で変更:
samesite='None'
(文字列)の使用が許可されました。警告
RFC 6265 は、ユーザーエージェントが少なくとも4096バイトのCookieをサポートする必要があると述べています。 多くのブラウザでは、これは最大サイズでもあります。 4096バイトを超えるCookieを保存しようとしても、Djangoは例外を発生させませんが、多くのブラウザーはCookieを正しく設定しません。
- HttpResponse.set_signed_cookie(key, value, salt=, max_age=None, expires=None, path='/', domain=None, secure=False, httponly=False, samesite=None)
set_cookie()と同様ですが、設定する前に暗号署名 Cookieを使用します。 HttpRequest.get_signed_cookie()と組み合わせて使用します。 オプションの
salt
引数を使用してキー強度を追加できますが、対応する HttpRequest.get_signed_cookie()呼び出しに渡すことを忘れないでください。バージョン3.1で変更:
samesite='None'
(文字列)の使用が許可されました。
- HttpResponse.delete_cookie(key, path='/', domain=None, samesite=None)
指定されたキーのCookieを削除します。 キーが存在しない場合、サイレントに失敗します。
Cookieの動作方法により、
path
とdomain
はset_cookie()
で使用した値と同じである必要があります。そうでない場合、Cookieが削除されない場合があります。バージョン2.2.15で変更:
samesite
引数が追加されました。
- HttpResponse.close()
- このメソッドは、要求の最後にWSGIサーバーによって直接呼び出されます。
- HttpResponse.write(content)
- このメソッドは、 HttpResponse インスタンスをファイルのようなオブジェクトにします。
- HttpResponse.flush()
- このメソッドは、 HttpResponse インスタンスをファイルのようなオブジェクトにします。
- HttpResponse.tell()
- このメソッドは、 HttpResponse インスタンスをファイルのようなオブジェクトにします。
- HttpResponse.getvalue()
- HttpResponse.content の値を返します。 このメソッドは、 HttpResponse インスタンスをストリームのようなオブジェクトにします。
- HttpResponse.readable()
- 常に
False
。 このメソッドは、 HttpResponse インスタンスをストリームのようなオブジェクトにします。
- HttpResponse.seekable()
- 常に
False
。 このメソッドは、 HttpResponse インスタンスをストリームのようなオブジェクトにします。
- HttpResponse.writable()
- 常に
True
。 このメソッドは、 HttpResponse インスタンスをストリームのようなオブジェクトにします。
- HttpResponse.writelines(lines)
- 行のリストを応答に書き込みます。 行区切り記号は追加されません。 このメソッドは、 HttpResponse インスタンスをストリームのようなオブジェクトにします。
HttpResponseサブクラス
Djangoには、さまざまなタイプのHTTP応答を処理するHttpResponse
サブクラスがいくつか含まれています。 HttpResponse
と同様に、これらのサブクラスは django.http に存在します。
- class HttpResponseRedirect
- コンストラクターへの最初の引数、つまりリダイレクト先のパスが必要です。 これは完全修飾URLにすることができます(例:
'https://www.yahoo.com/search/'
)、ドメインのない絶対パス(例:'/search/'
)、または相対パス(例:'search/'
)。 その最後のケースでは、クライアントブラウザは現在のパスに従って完全なURL自体を再構築します。 その他のオプションのコンストラクター引数については、 HttpResponse を参照してください。 これはHTTPステータスコード302を返すことに注意してください。
- url
- この読み取り専用属性は、応答がリダイレクトされるURLを表します(
Location
応答ヘッダーと同等)。
- class HttpResponsePermanentRedirect
- HttpResponseRedirect と同様ですが、「見つかった」リダイレクト(ステータスコード302)ではなく、永続的なリダイレクト(HTTPステータスコード301)を返します。
- class HttpResponseNotModified
- コンストラクターは引数をとらないため、この応答にコンテンツを追加しないでください。 これを使用して、ユーザーの最後の要求(ステータスコード304)以降にページが変更されていないことを指定します。
- class HttpResponseBadRequest
- HttpResponse と同じように機能しますが、400のステータスコードを使用します。
- class HttpResponseNotFound
- HttpResponse と同じように機能しますが、404ステータスコードを使用します。
- class HttpResponseForbidden
- HttpResponse と同じように機能しますが、403ステータスコードを使用します。
- class HttpResponseNotAllowed
- HttpResponse と似ていますが、405ステータスコードを使用します。 コンストラクターへの最初の引数が必要です:許可されたメソッドのリスト(例:
['GET', 'POST']
)。
- class HttpResponseGone
- HttpResponse と同じように機能しますが、410ステータスコードを使用します。
- class HttpResponseServerError
- HttpResponse と同じように機能しますが、500ステータスコードを使用します。
ノート
HttpResponse のカスタムサブクラスがrender
メソッドを実装している場合、Djangoはそれを SimpleTemplateResponse をエミュレートするものとして扱い、render
メソッド自体が有効な応答オブジェクト。
カスタム応答クラス
Djangoが提供していない応答クラスが必要な場合は、http.HTTPStatus
を使用して作成できます。 例えば:
JsonResponseオブジェクト
- class JsonResponse(data, encoder=DjangoJSONEncoder, safe=True, json_dumps_params=None, **kwargs)
JSONエンコードされた応答の作成に役立つ HttpResponse サブクラス。 スーパークラスからほとんどの動作を継承しますが、いくつかの違いがあります。
デフォルトの
Content-Type
ヘッダーは application / json に設定されています。最初のパラメータ
data
は、dict
インスタンスである必要があります。safe
パラメーターがFalse
に設定されている場合(以下を参照)、JSONでシリアル化可能な任意のオブジェクトにすることができます。データのシリアル化には、デフォルトで django.core.serializers.json.DjangoJSONEncoder である
encoder
が使用されます。 このシリアライザーの詳細については、 JSONシリアル化を参照してください。safe
ブールパラメータのデフォルトはTrue
です。False
に設定されている場合、任意のオブジェクトをシリアル化に渡すことができます(それ以外の場合は、dict
インスタンスのみが許可されます)。safe
がTrue
であり、dict
以外のオブジェクトが最初の引数として渡された場合、TypeError
が発生します。json_dumps_params
パラメーターは、応答の生成に使用されるjson.dumps()
呼び出しに渡すキーワード引数の辞書です。
使用法
一般的な使用法は次のようになります。
非辞書オブジェクトのシリアル化
dict
以外のオブジェクトをシリアル化するには、safe
パラメーターをFalse
に設定する必要があります。
safe=False
を渡さないと、TypeError
が発生します。
警告
ECMAScript の第5版より前は、JavaScript Array
コンストラクターをポイズニングすることが可能でした。 このため、Djangoはデフォルトで非dictオブジェクトを JsonResponse コンストラクターに渡すことを許可していません。 ただし、最近のほとんどのブラウザは、この攻撃ベクトルを削除するEcmaScript5を実装しています。 したがって、このセキュリティ対策を無効にすることができます。
デフォルトのJSONエンコーダーの変更
別のJSONエンコーダークラスを使用する必要がある場合は、encoder
パラメーターをコンストラクターメソッドに渡すことができます。
StreamingHttpResponseオブジェクト
- class StreamingHttpResponse
StreamingHttpResponse クラスは、Djangoからブラウザーに応答をストリーミングするために使用されます。 応答の生成に時間がかかりすぎたり、メモリを使いすぎたりする場合は、これを実行することをお勧めします。 たとえば、大きなCSVファイルを生成する場合に便利です。
パフォーマンスに関する考慮事項
Djangoは短期間のリクエスト向けに設計されています。 ストリーミング応答は、応答の全期間にわたってワーカープロセスを結び付けます。 これにより、パフォーマンスが低下する可能性があります。
一般的に言って、ストリーミングされた応答に頼るのではなく、要求と応答のサイクルの外で高価なタスクを実行する必要があります。
StreamingHttpResponse は、APIがわずかに異なるため、 HttpResponse のサブクラスではありません。 ただし、ほとんど同じですが、次の顕著な違いがあります。
- コンテンツとしてバイト文字列を生成するイテレータを指定する必要があります。
- 応答オブジェクト自体を反復処理する場合を除いて、そのコンテンツにアクセスすることはできません。 これは、応答がクライアントに返されるときにのみ発生するはずです。
content
属性はありません。 代わりに、 streaming_content 属性があります。- ファイルのようなオブジェクト
tell()
またはwrite()
メソッドは使用できません。 これを行うと、例外が発生します。
StreamingHttpResponse は、データをクライアントに転送する前にコンテンツ全体を繰り返さないことが絶対に必要な状況でのみ使用する必要があります。 コンテンツにアクセスできないため、多くのミドルウェアは正常に機能しません。 たとえば、ETag
およびContent-Length
ヘッダーは、ストリーミング応答用に生成できません。
属性
- StreamingHttpResponse.streaming_content
- 応答コンテンツのイテレータ、 HttpResponse.charset に従ってエンコードされたバイト文字列。
- StreamingHttpResponse.status_code
応答の HTTPステータスコード。
reason_phrase が明示的に設定されていない限り、コンストラクターの外部で
status_code
の値を変更すると、reason_phrase
の値も変更されます。
- StreamingHttpResponse.reason_phrase
応答のHTTP理由句。 HTTP標準のデフォルトの理由フレーズを使用します。
明示的に設定されていない限り、
reason_phrase
は status_code の値によって決定されます。
- StreamingHttpResponse.streaming
- これは常に
True
です。
FileResponseオブジェクト
- class FileResponse(open_file, as_attachment=False, filename=, **kwargs)
FileResponse は、バイナリファイル用に最適化された StreamingHttpResponse のサブクラスです。 wsgiサーバーから提供された場合は wsgi.file_wrapper を使用し、それ以外の場合はファイルを小さなチャンクでストリーミングします。
as_attachment=True
の場合、Content-Disposition
ヘッダーはattachment
に設定され、ブラウザーにファイルをダウンロードとしてユーザーに提供するように要求します。 それ以外の場合、値がinline
(ブラウザーのデフォルト)のContent-Disposition
ヘッダーは、ファイル名が使用可能な場合にのみ設定されます。open_file
に名前がない場合、またはopen_file
の名前が適切でない場合は、filename
パラメーターを使用してカスタムファイル名を指定してください。io.BytesIO
のようなファイルのようなオブジェクトを渡す場合は、FileResponse
に渡す前に、seek()
に渡すのがタスクであることに注意してください。Content-Length
およびContent-Type
ヘッダーは、open_file
の内容から推測できる場合に自動的に設定されます。
FileResponse
は、バイナリコンテンツを持つファイルのようなオブジェクトを受け入れます。たとえば、次のようにバイナリモードで開いているファイルです。
ファイルは自動的に閉じられるため、コンテキストマネージャーで開かないでください。
メソッド
- FileResponse.set_headers(open_file)
- このメソッドは、応答の初期化中に自動的に呼び出され、
open_file
に応じてさまざまなヘッダー(Content-Length
、Content-Type
、およびContent-Disposition
)を設定します。