Django は、システムを通じてステータスを渡すために、リクエストとレスポンスのオブジェクトを使います。
\nあるページがリクエストされたとき、Django はリクエストに関するメタデータを含んだ HttpRequest オブジェクトを生成します。それから Django は HttpRequest をビュー関数の最初の関数として渡し、適切なビューを読み込みます。あらゆるビューは HttpResponse オブジェクトを返す必要があります。
このドキュメントでは、HttpRequest と HttpResponse オブジェクトの API を説明しています。これは django.http モジュールにて定義されています。
HttpRequest オブジェクトLink to this heading#特に記載がない限り、全ての属性は読み取り専用だと考えてください。
\nリクエストのスキームを表す文字列です (通常は http か https)。
生の HTTP リクエストボディをバイト文字列として。これは、従来の HTML フォームとは異なる方法でデータを処理するのに便利です：バイナリイメージ、XML ペイロードなど。従来のフォームデータを処理する場合は、HttpRequest.POST を使用してください。
HttpRequest.read() や HttpRequest.readline() を用いて、ファイルのようなインタフェースから HttpRequest を読み取ることもできます。これらの I/O ストリームメソッドを用いてリクエストを読み取った 後に body 属性にアクセスすると、RawPostDataException が発生します。
要求されたページへのフルパスを表す文字列であり、scheme、ドメイン、クエリ文字列は含みません。
\n例: "/music/bands/the_beatles/"
一部のWebサーバー構成では、ホスト名の後のURLがスクリプトプレフィックス部分とパス情報部分に分割されます。path_info 属性は、使用されるWebサーバーに関わらず常にパス情報部分を含んでいます。これを path の代わりに使用することで、テストサーバーとデプロイメントサーバー間でコードを移動させやすくなります。
たとえば、アプリケーションの WSGIScriptAlias が "/minfo" に設定されている場合、path が "/minfo/music/bands/the_beatles/" である一方、path_info は "/music/bands/the_beatles/" となる可能性があります。
リクエストで使用された HTTP メソッドを表す文字列です。この値は常に大文字となることが保証されています。たとえば、次のようになります。
\nif request.method == "GET":\n do_something()\nelif request.method == "POST":\n do_something_else()\nフォーム提出データをデコードする際に使用されている現在のエンコーディングを表す文字列（または None で、これは DEFAULT_CHARSET 設定が使用されることを意味します）。この属性に書き込むことで、フォームデータにアクセスする際に使用されるエンコーディングを変更できます。その後の属性アクセス（GET や POST からの読み取りなど）は、新しい encoding 値を使用します。フォームデータが DEFAULT_CHARSET エンコーディングでないことがわかっている場合に便利です。
リクエストの MIME タイプを表す文字列です。CONTENT_TYPE から識別されます。
CONTENT_TYPE ヘッダに含まれる、キーと値のパラーメータのディクショナリです。
渡された HTTP GET パラメータを含む、ディクショナリライクのオブジェクトです。後述の QueryDict のドキュメントを参照してください。
リクエストにフォームデータが含まれている場合に、すべての与えられた HTTP POST パラメータを含む辞書のようなオブジェクト。以下の QueryDict ドキュメントを参照してください。リクエストにポストされた生のデータや非フォームデータにアクセスする必要がある場合は、代わりに HttpRequest.body 属性を通じてアクセスしてください。
POST メソッドでフォームデータが含まれていない場合に、空の POST ディクショナリを備えたリクエストが発生する可能性があります。そのため、POST メソッドの使用を確認するために if request.POST を使用すべきではありません。代わりに、 if request.method == "POST" を使用してください (HttpRequest.method を参照)。
POST には file-upload の情報が含まれ ません 。詳しくは FILES を参照してください。
すべてのクッキーが格納されたディクショナリです。キーと値は文字列です。
\nFILES は、アップロードされた全てのファイルを含む辞書型のオブジェクトです。FILES の各キーは <input type="file" name=""> の name から成ります。FILES の各値は UploadedFile です。
詳細については、ファイルの管理 を参照してください。
\nFILES には、リクエストメソッドが POST で、リクエストに投稿した <form> に enctype="multipart/form-data" が設定されていた場合にのみデータが含まれます。それ以外の場合、FILES は空の辞書のようなオブジェクトになります。
利用できるすべての HTTP ヘッダーが格納されたディクショナリです。利用可能なヘッダーはクライアントとサーバーによって異なりますが、以下に例を示します。
\nCONTENT_LENGTH -- リクエスト本文の (文字列としての) 長さです。
CONTENT_TYPE -- リクエスト本文の MIME タイプです。
HTTP_ACCEPT -- レスポンスに対して受け入れ可能なコンテンツのタイプです。
HTTP_ACCEPT_ENCODING -- レスポンスに対して受け入れ可能なエンコーディングです。
HTTP_ACCEPT_LANGUAGE -- レスポンスに対して受け入れ可能な言語です。
HTTP_HOST -- クライアントによって送信された HTTP Host ヘッダです。
HTTP_REFERER -- (存在する場合) リファラページです。
HTTP_USER_AGENT -- クライアントのユーザエージェント文字列です。
QUERY_STRING -- クエリ文字列で、単一の (未解析の) 文字列です。
REMOTE_ADDR -- クライアントの IP アドレスです。
REMOTE_HOST -- クライアントのホスト名です。
REMOTE_USER -- ウェブサーバーによって認証されたユーザー(もしあれば)。
REQUEST_METHOD -- "GET" や "POST" といったです。
SERVER_NAME -- サーバのホスト名です。
SERVER_PORT -- (文字列としての) サーバのポートです。
上記の CONTENT_LENGTH と CONTENT_TYPE を除き、リクエストの HTTP ヘッダーは、すべての文字を大文字に変換し、ハイフンをアンダースコアに置き換え、名前に HTTP_ プレフィックスを追加することで META キーに変換されます。たとえば、X-Bender というヘッダーは META キー HTTP_X_BENDER にマッピングされます。
runserver では、名前にアンダースコアを含むヘッダーはすべて削除されるため、META にそれらが表示されません。これにより、WSGI 環境変数内のアンダースコアとダッシュの曖昧さに基づくヘッダー・スプーフィングが防がれます。この動作は、Nginx や Apache 2.4+ のようなウェブサーバーと一致しています。
HttpRequest.headers は CONTENT_LENGTH と CONTENT_TYPE を含む、全てのHTTPプレフィックス付きヘッダーにアクセスするより簡単な方法です。
リクエストからHTTPプリフィックスヘッダー全体 (Content-Length と Content-Type を含む) にアクセスを提供する、大文字小文字を区別しない辞書風オブジェクトです。
各ヘッダーの名前は、表示される際にタイトルケース (例: User-Agent) でスタイリズされます。ヘッダーは大文字小文字を区別せずにアクセスできます。
>>> request.headers\n{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}\n\n>>> "User-Agent" in request.headers\nTrue\n>>> "user-agent" in request.headers\nTrue\n\n>>> request.headers["User-Agent"]\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)\n>>> request.headers["user-agent"]\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)\n\n>>> request.headers.get("User-Agent")\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)\n>>> request.headers.get("user-agent")\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)\nたとえば Django テンプレートでの使用において、ヘッダーはハイフンの代わりにアンダースコアを使用してもルックアップできます。
\n{{ request.headers.user_agent }}\n解決されたURLを表す ResolverMatch のインスタンスです。この属性は、URLの解決が行われた後にのみ設定されます。つまり、全てのビューで利用可能ですが、URLの解決が行われる前に実行されるミドルウェアでは利用できません (process_view() では使用できます)。
Django はこれらの属性を自分で設定することはありませんが、アプリケーション側で設定された場合にはその値を利用します。
\nThe url template tag will use its value as the current_app\nargument to reverse().
この値は、現在のリクエストに対する root URLconf として使用され、設定の ROOT_URLCONF を上書きします。詳しくは Django のリクエスト処理 を参照してください。
urlconf は None に設定することで、それまでにミドルウェアで行われた変更を取り消し、元の ROOT_URLCONF を使用するようにできます。
これは、現在のリクエストに対して DEFAULT_EXCEPTION_REPORTER_FILTER の代わりに使用されます。詳細については、 カスタムエラーレポート を参照してください。
これは、現在のリクエストに対して DEFAULT_EXCEPTION_REPORTER の代わりに使用されます。詳細については カスタムエラーレポート を参照してください。
Django の contrib アプリなどのミドルウェアの一部は、リクエストに属性を設定します。もし、リクエストに属性が設定されていない場合は、MIDDLEWARE リスト中に適切なミドルウェアが含まれているかを確認してください。
SessionMiddleware は、現在のセッションを表す、読み書き可能でディクショナリライクなオブジェクトを設定します。
From the CurrentSiteMiddleware:\nAn instance of Site or\nRequestSite as returned by\nget_current_site()\nrepresenting the current site.
AuthenticationMiddleware から: 現在ログインしているユーザーを表す AUTH_USER_MODEL のインスタンスです。ユーザーが現在ログインしていない場合、 user は AnonymousUser のインスタンスに設定されます。 is_authenticated を使用して、それらを区別できます。例えば、こうです:
if request.user.is_authenticated:\n ... # Do something for logged-in users.\nelse:\n ... # Do something for anonymous users.\nauser() メソッドは同じ機能を提供しますが、非同期コンテキストから使用できます。
AuthenticationMiddleware から: コルーチン。現在ログインしているユーザーを表す AUTH_USER_MODEL のインスタンスを返します。もしユーザーが現在ログインしていない場合、auser は AnonymousUser のインスタンスを返します。これは user 属性に似ていますが、非同期コンテキストでも機能します。
リクエストの発信元ホストを返します。この情報は、順番に HTTP_X_FORWARDED_HOST (もし USE_X_FORWARDED_HOST が有効な場合) および HTTP_HOST ヘッダーから取得されます。これらが値を提供しない場合、メソッドは SERVER_NAME と SERVER_PORT の組み合わせを使用します。詳細は PEP 3333 で説明されています。
例: "127.0.0.1:8000"
ホストが ALLOWED_HOSTS にないか、ドメイン名が RFC 1034/1035 に従っていない場合、 django.core.exceptions.DisallowedHost を発生させます。
リクエストの元となったポートを、 HTTP_X_FORWARDED_PORT と SERVER_PORT の META 変数から、その順に使用して情報を取得し返します (ただし、 USE_X_FORWARDED_PORT が有効になっている場合)。
必要に応じて、 path にクエリ文字列を追加して返します。
例: "/minfo/music/bands/the_beatles/?print=true"
get_full_path() と似ていますが、 path の代わりに path_info を使用します。
例: "/music/bands/the_beatles/?print=true"
location の絶対URI形式を返します。もし location が指定されていない場合、request.get_full_path() が location に設定されます。
もし場所がすでに絶対 URI である場合、それは変更されません。そうでない場合、このリクエストで利用可能なサーバ変数を使用して絶対 URI が構築されます。例えば:
\n>>> request.build_absolute_uri()\n'https://example.com/music/bands/the_beatles/?print=true'\n>>> request.build_absolute_uri("/bands/")\n'https://example.com/bands/'\n>>> request.build_absolute_uri("https://example2.com/bands/")\n'https://example2.com/bands/'\n署名付きクッキーの値を返します。署名が無効である場合は django.core.signing.BadSignature 例外が発生します。default 引数を提供した場合、例外は抑制され、代わりにそのデフォルト値が返されます。
The optional salt argument can be used to put the cookie into a\nseparate signature namespace. If supplied, the max_age argument will\nbe checked against the signed timestamp attached to the cookie value to\nensure the cookie is not older than max_age seconds.
Cookies signed by older Django versions are accepted by default for\nbackwards compatibility. Set SIGNED_COOKIE_LEGACY_SALT_FALLBACK\nto False to reject them.
例:
\n>>> request.get_signed_cookie("name")\n'Tony'\n>>> request.get_signed_cookie("name", salt="name-salt")\n'Tony' # assuming cookie was set using the same salt\n>>> request.get_signed_cookie("nonexistent-cookie")\nKeyError: 'nonexistent-cookie'\n>>> request.get_signed_cookie("nonexistent-cookie", False)\nFalse\n>>> request.get_signed_cookie("cookie-that-was-tampered-with")\nBadSignature: ...\n>>> request.get_signed_cookie("name", max_age=60)\nSignatureExpired: Signature age 1677.3839159 > 60 seconds\n>>> request.get_signed_cookie("name", False, max_age=60)\nFalse\n詳細については、 暗号署名 を参照してください。
\n\nリクエストがセキュアである場合、つまりHTTPSで行われた場合に True を返します。
Accept ヘッダーに基づいて、 media_types の中から優先される MIME タイプを返します。クライアントが指定されたいずれのタイプも受け入れない場合は None を返します。
クライアントが Accept ヘッダーとして text/html,application/json;q=0.8 を送信したと仮定します。
>>> request.get_preferred_type(["text/html", "application/json"])\n"text/html"\n>>> request.get_preferred_type(["application/json", "text/plain"])\n"application/json"\n>>> request.get_preferred_type(["application/xml", "text/plain"])\nNone\nMIME タイプにパラメーターが含まれている場合、それらも優先されるメディアタイプを判断する際に考慮されます。たとえば、Accept ヘッダーが text/vcard;version=3.0,text/html;q=0.5 の場合、 request.get_preferred_type() の返り値は、利用可能なメディアタイプによって異なります：
>>> request.get_preferred_type(\n... [\n... "text/vcard; version=4.0",\n... "text/vcard; version=3.0",\n... "text/vcard",\n... "text/directory",\n... ]\n... )\n"text/vcard; version=3.0"\n>>> request.get_preferred_type(\n... [\n... "text/vcard; version=4.0",\n... "text/html",\n... ]\n... )\n"text/html"\n>>> request.get_preferred_type(\n... [\n... "text/vcard; version=4.0",\n... "text/vcard",\n... "text/directory",\n... ]\n... )\nNone\n（コンテンツネゴシエーションの詳細な仕組みについては、 RFC 9110 Section 12.5.1 を参照してください。）
\nほとんどのブラウザはデフォルトで Accept: */* を送信するため、特に優先順位が指定されません。その場合、media_types の最初の項目が返されます。
API リクエストで明示的に Accept ヘッダーを設定すると、そのクライアントに対してのみ異なるコンテンツタイプを返すのに役立ちます。 Accept ヘッダーに基づいて異なるコンテンツを返す例については コンテンツネゴシエーションの例 を参照してください。
リクエストの Accept ヘッダが mime_type 引数と一致する場合に True を返します。
>>> request.accepts("text/html")\nTrue\n大半のブラウザは Accept: */* をデフォルトで送信するので、すべてのコンテンツタイプに対して True を返します。
accepts() を用いて Accept ヘッダーに基づき異なるコンテンツを返す例については、 コンテンツネゴシエーションの例 を参照してください。
HttpRequest インスタンスから読み取るためのファイルライクなインターフェースを実装するメソッドです。これにより、着信リクエストをストリーミング形式で消費することが可能になります。一般的な使用例は、大きなXMLペイロードをメモリ内で完全なXMLツリーを構築することなく、繰り返しパーサーで処理する場合です。
この標準インターフェースを用いると、 HttpRequest インスタンスは ElementTree のようなXMLパーサーに直接渡すことができます。
import xml.etree.ElementTree as ET\n\nfor element in ET.iterparse(request):\n process(element)\nQueryDict オブジェクトLink to this heading#HttpRequest オブジェクト内では、GET と POST 属性は django.http.QueryDict のインスタンスです。これは、同一のキーに対する複数の値を扱うためにカスタマイズされた、辞書型に似たクラスです。これが必要なのは、いくつかの HTML (特に <select multiple>) が同一キーで複数の値を渡すからです。
request.POST や request.GET の QueryDictは、通常の request/response 内でアクセスするときには編集不可です。編集可能なものを取得するには、QueryDict.copy() を使う必要があります。
QueryDict はディクショナリのサブクラスなので、標準的なディクショナリのメソッドを全て実装しています。当てはまらないのはおおむね以下の通りです:
QueryDictに基づいて QueryDict オブジェクトをインスタンス化します。
>>> QueryDict("a=1&a=2&c=3")\n<QueryDict: {'a': ['1', '2'], 'c': ['3']}>\nquery_string が渡されなかった場合は、QueryDict 空となります (何のキーや値も持ちません)。
使用する QueryDict のほとんど、特に request.POST や request.GET における場合、編集不可となっています。自分でインスタンスを生成する場合は、__init__() に mutable=True を渡すことで編集可能にできます。
キーとバリューの両方を設定するための文字列は、encoding から str に変換されます。encoding がセットされていない場合、DEFAULT_CHARSET がデフォルトとなります。
新しい QueryDict を作成します。キーは iterable で、各値は value になります。例えば:
>>> QueryDict.fromkeys(["a", "a", "b"], value="val")\n<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>\n指定されたキーに対する最後の値を返します。キーは存在するが値がない場合は空リスト（ [] ）を返します。キーが存在しない場合は django.utils.datastructures.MultiValueDictKeyError を送出します。（これは Python 標準の KeyError のサブクラスなので、単に KeyError を捕捉しても構いません。）
>>> q = QueryDict("a=1&a=2&a=3", mutable=True)\n>>> q.__getitem__("a")\n'3'\n>>> q.__setitem__("b", [])\n>>> q.__getitem__("b")\n[]\n指定したキーを [value] (各要素が value のリスト) にセットします。 副作用を持つ他のディクショナリ関数と同様に、編集可能な QueryDict (QueryDict.copy() で作成されたものなど) のみで呼び出し可能です.
指定したキーがセットされている場合 True を返します。例えば if "foo" in request.GET を実行するのと同じです。
__getitem__() と同じロジックを使いますが、キーが存在しない場合のデフォルト値をフックします。
dict.setdefault() に似ていますが、内部では __setitem__() を使用します。
QueryDict または辞書のどちらかを取ります。 dict.update() と似ていますが、現在の辞書の項目を置き換えるのではなく 追加 します。例えば:
>>> q = QueryDict("a=1", mutable=True)\n>>> q.update({"a": "2"})\n>>> q.getlist("a")\n['1', '2']\n>>> q["a"] # returns the last\n'2'\ndict.items() と似ていますが、これは __getitem__() と同じ最後の値のロジックを使用し、ビューオブジェクトの代わりにイテレータオブジェクトを返します。例えば:
>>> q = QueryDict("a=1&a=2&a=3")\n>>> list(q.items())\n[('a', '3')]\ndict.values() のように、__getitem__() と同じ最後の値のロジックを使用しますが、ビューオブジェクトの代わりにイテレータを返します。例えば:
>>> q = QueryDict("a=1&a=2&a=3")\n>>> list(q.values())\n['3']\n加えて、QueryDict は以下のメソッドを持ちます:
copy.deepcopy() を使用してオブジェクトのコピーを返します。このコピーは、元のオブジェクトがイミュータブルであったとしても、ミュータブルです。
リクエストされたキーのデータのリストを返します。キーが存在しない場合には、 default が None であれば空のリストを返します。デフォルト値がリストでない限り、リストを返すことが保証されています。
指定されたキーを list_ に設定します ( __setitem__() と異なります)。
key に関連付けられた内部リストに項目を追加します。
\nsetdefault() に似ていますが、単一の値の代わりに値のリストを取ります。
Like items(), except it includes all values, as a list, for each\nmember of the dictionary. For example:
>>> q = QueryDict("a=1&a=2&a=3")\n>>> q.lists()\n[('a', ['1', '2', '3'])]\n指定されたキーに対応する値のリストを返し、それらを辞書から削除します。キーが存在しない場合は KeyError を発生させます。例えば:
>>> q = QueryDict("a=1&a=2&a=3", mutable=True)\n>>> q.pop("a")\n['1', '2', '3']\n辞書の任意のメンバーを削除し (順序の概念がないため)、キーとキーに対するすべての値のリストを含む2値タプルを返します。空の辞書に対して呼び出されると KeyError を発生させます。例えば:
>>> q = QueryDict("a=1&a=2&a=3", mutable=True)\n>>> q.popitem()\n('a', ['1', '2', '3'])\nQueryDict の各(key, list)ペアに対して、 dict 形式の表現を返します。 dict は、リストの中の要素の1つである item に対して、(key, item) のペアを持ちます。これは、 QueryDict.__getitem__() と同じロジックを使用します。
>>> q = QueryDict("a=1&a=3&a=5")\n>>> q.dict()\n{'a': '5'}\nクエリ文字列形式のデータを文字列で返します。例えば：
\n>>> q = QueryDict("a=2&b=3&b=5")\n>>> q.urlencode()\n'a=2&b=3&b=5'\nsafe パラメータを使って、エンコードを不要とする文字を渡すことができます。たとえば:
>>> q = QueryDict(mutable=True)\n>>> q["next"] = "/a&b/"\n>>> q.urlencode(safe="/")\n'next=/a%26b/'\nHttpResponse オブジェクトLink to this heading#Django によって自動的に生成される HttpRequest オブジェクトとは対照的に、HttpResponse オブジェクトの作成はあなたの責任です。プログラム内に記述されるあらゆるビューは、HttpResponse をインスタンス化し、データを格納して返す必要があります。
HttpResponse クラスは django.http モジュール内に存在します。
一般的な使い方としては、ページのコンテンツを文字列、バイト文字列、または memoryview として、 HttpResponse コンストラクタに渡します。
>>> from django.http import HttpResponse\n>>> response = HttpResponse("Here's the text of the web page.")\n>>> response = HttpResponse("Text only, please.", content_type="text/plain")\n>>> response = HttpResponse(b"Bytestrings are also accepted.")\n>>> response = HttpResponse(memoryview(b"Memoryview as well."))\nしかし、内容を段階的に追加したい場合は、 response をファイルライクオブジェクトとして使用できます:
>>> response = HttpResponse()\n>>> response.write("<p>Here's the text of the web page.</p>")\n>>> response.write("<p>Here's another paragraph.</p>")\n最後に、文字列ではなくイテレータを HttpResponse に渡すこともできます。 HttpResponse はイテレータを即座に受け取り、その内容を文字列として保存し、破棄します。ファイルやジェネレータのような close() メソッドを持つオブジェクトは、すぐに閉じられます。
レスポンスに対して、イテレータからクライアントにストリーミングさせる必要がある場合には、代わりに StreamingHttpResponse クラスを使う必要があります。
レスポンスでヘッダーフィールドを設定または削除するには、 HttpResponse.headers を使用してください。
>>> response = HttpResponse()\n>>> response.headers["Age"] = 120\n>>> del response.headers["Age"]\nレスポンスを辞書のように扱うことで、ヘッダーを操作することもできます:
\n>>> response = HttpResponse()\n>>> response["Age"] = 120\n>>> del response["Age"]\nこれは HttpResponse.headers へのプロキシで、 HttpResponse が提供する本来のインタフェースです。
このインターフェースを使用する際、辞書とは異なり、ヘッダーフィールドが存在しない場合に del が KeyError を発生させることはありません。
インスタンス化の際にもヘッダーを設定できます:
\n>>> response = HttpResponse(headers={"Age": 120})\nCache-Control および Vary ヘッダーフィールドを設定するには、これらのフィールドが複数のカンマ区切りの値を持ち得るため、 django.utils.cache から patch_cache_control() と patch_vary_headers() メソッドを使用することが推奨されます。"patch" メソッドは、ミドルウェアによって追加された他の値が削除されないように保証します。
HTTP ヘッダフィールドには改行を含めることはできません。改行文字 (CR または LF) を含むヘッダフィールドを設定しようとすると、BadHeaderError が発生します。
ブラウザにレスポンスをファイル添付として扱うように指示するためには、Content-Type と Content-Disposition ヘッダを設定します。例えば、Microsoft Excel スプレッドシートを返す方法は以下のようになります:
>>> response = HttpResponse(\n... my_data,\n... headers={\n... "Content-Type": "application/vnd.ms-excel",\n... "Content-Disposition": 'attachment; filename="foo.xls"',\n... },\n... )\nContent-Disposition ヘッダについては Django 固有のものはありませんが、その構文を忘れやすいので、ここに含めています。
必要に応じて文字列からエンコードされた、コンテンツを表すバイト文字列。
\nレスポンスの HttpResponse.charset （空の場合は UTF-8 がデフォルト）を用いてデコードした、 HttpResponse.content の文字列表現。
A http.cookies.SimpleCookie object holding the cookies included\nin the response.
大文字小文字を区別しない辞書型オブジェクトで、Set-Cookie ヘッダを除くすべてのHTTPヘッダに対するインターフェイスを提供します。 ヘッダーフィールドをセットする および HttpResponse.cookies を参照してください。
応答がエンコードされる文字セットを示す文字列です。 HttpResponse のインスタンス化の際に指定されなかった場合、 content_type から抽出され、もしこれが失敗した場合は、 DEFAULT_CHARSET 設定が使用されます。
レスポンスの HTTP ステータスコード 。
\nreason_phrase が明示的にセットされていない限り、コンストラクタの外で status_code の値を変更すると reason_phrase の値も変更されます。
レスポンスの HTTP reason フレーズです。これは HTTP 標準の デフォルトの reason フレーズを使用します。
\nreason_phrase が明示的に設定されていない場合、 status_code の値に基づいて決定されます。
これは常に False です。
この属性は、ミドルウェアが通常のレスポンスとは違う形でストリーミングレスポンスを扱えるようにするために存在しています。
\nレスポンスが閉じられた場合、True となります。
指定されたページ内容、コンテンツタイプ、およびヘッダーを持つ HttpResponse オブジェクトをインスタンス化します。
content は、最も一般的にはイテレータ、バイト文字列、 memoryview 、または文字列です。その他の型は、文字列表現をエンコードしてバイト文字列に変換されます。イテレータは文字列またはバイト文字列を返すべきで、それらはレスポンスの内容を形成するために連結されます。
content_type は、MIME タイプであり、オプションで文字セットエンコーディングを指定して HTTP Content-Type ヘッダを埋めるために使用されます。指定されていない場合、デフォルトでは 'text/html' と DEFAULT_CHARSET 設定によって形成されます: つまり "text/html; charset=utf-8" 。
status is the HTTP status code for the\nresponse. You can use Python's http.HTTPStatus for meaningful\naliases, such as HTTPStatus.NO_CONTENT.
reason は HTTP レスポンスフレーズです。指定しない場合、デフォルトのフレーズが使用されます。
charset は、レスポンスがエンコードされる文字セットです。もし指定されていない場合、content_type から抽出されます。それが失敗した場合は、 DEFAULT_CHARSET 設定が使用されます。
headers はレスポンス用のHTTPヘッダーの dict です。
指定されたヘッダ名に指定された値を設定します。 header と value は共に文字列であるべきです。
指定された名前のヘッダーを削除します。ヘッダーが存在しなくても、静かに失敗します。大文字小文字を区別しません。
\n指定されたヘッダ名の値を返します。大文字小文字を区別しません。
\n指定されたヘッダーの値を返します。ヘッダーが存在しない場合は、alternate を返します。
指定された名前のヘッダーが存在するかどうかを大文字小文字を区別せずにチェックし、True または False を返します。
レスポンスのHTTPヘッダに対して、 dict.items() のように動作します。
ヘッダーがまだ設定されていない場合に、ヘッダーを設定します。
\nクッキーを設定します。パラメータは、Python標準ライブラリ内の Morsel クッキーオブジェクトと同じです。
max_age は timedelta オブジェクト、整数秒数、または None (デフォルト) である必要があります。これにより、クッキーの有効期限はクライアントのブラウザセッションが終了するまでとなります。 expires が指定されていない場合は自動的に計算されます。
expires は、 "Wdy, DD-Mon-YY HH:MM:SS GMT" 形式の文字列か、UTCの datetime.datetime オブジェクトであるべきです。もし expires が datetime オブジェクトである場合、 max_age が計算されます。
クロスドメインのクッキーを設定したい場合は、domain を使用してください。例えば、 domain="example.com" とすると、www.example.com、blog.example.com などのドメインから読み取れるクッキーが設定されます。そうでない場合、クッキーは設定したドメインのみから読み取れます。
secure=True を使用すると、リクエストが https スキームで行われた場合にのみ、クッキーがサーバーに送信されるようになります。
クライアントサイドのJavaScriptがクッキーにアクセスするのを防ぎたい場合は、httponly=True を使用してください。
HttpOnly は、Set-Cookie HTTP レスポンスヘッダーに含まれるフラグです。これは、クッキーの RFC 6265 標準の一部であり、クライアントサイドのスクリプトが保護されたクッキーデータにアクセスするリスクを軽減する有用な方法です。
\nsamesite='Strict' や samesite='Lax' を使用して、ブラウザにクロスオリジンリクエストを行う際にこのクッキーを送信しないよう指示します。 SameSite はすべてのブラウザに対応しているわけではないため、DjangoのCSRF保護の代わりとなるものではありませんが、防御の深度を増すための措置です。
samesite='None' (文字列) を使えば、このクッキーが同一サイトおよびクロスサイトのすべてのリクエストに送信されることを明示できます。
Like set_cookie(), but\ncryptographic signing the cookie before setting\nit. Use in conjunction with HttpRequest.get_signed_cookie().\nYou can use the optional salt argument to put the cookie into a\nseparate signature namespace, but you will need to remember to pass it to\nthe corresponding\nHttpRequest.get_signed_cookie() call.
指定されたキーを持つクッキーを削除します。キーが存在しない場合は、静かに失敗します。
\nクッキーの動作方法により、 path と domain は set_cookie() で使用した値と同じでなければなりません。そうでない場合、クッキーが削除されない可能性があります。
This method is called at the end of the request directly by the WSGI\nor ASGI server.
\nこのメソッドは、 HttpResponse インスタンスをファイルライクオブジェクトにします。
このメソッドは、 HttpResponse インスタンスをファイルライクオブジェクトにします。
このメソッドは、 HttpResponse インスタンスをファイルライクオブジェクトにします。
HttpResponse.content の値を返します。このメソッドにより、 HttpResponse インスタンスはストリームライクオブジェクトになります。
常に False です。このメソッドは HttpResponse インスタンスをストリームライクオブジェクトにします。
常に False です。このメソッドは HttpResponse インスタンスをストリームライクオブジェクトにします。
常に True です。このメソッドは HttpResponse インスタンスをストリームライクオブジェクトにします。
レスポンスに行のリストを書き込みます。行区切りは追加されません。このメソッドは、 HttpResponse インスタンスをストリームライクオブジェクトにします。
HttpResponse サブクラスLink to this heading#Djangoには、異なるタイプのHTTPレスポンスを処理するための HttpResponse のサブクラスがいくつか含まれています。 HttpResponse と同様に、これらのサブクラスは django.http に存在します。
コンストラクタの第1引数は必須で、リダイレクト先のパスを指定します。これは、完全修飾URL（例： 'https://www.yahoo.com/search/' ）、ドメインを含まない絶対パス（例： '/search/' ）、あるいは相対パス（例： 'search/' ）のいずれでも構いません。最後のケースでは、クライアントのブラウザが現在のパスに基づいて完全なURLを自動的に再構成します。
コンストラクタはオプションの preserve_request キーワード引数を受け付け、既定値は False です。この場合、302 ステータスコードのレスポンスが生成されます。 preserve_request が True の場合は、代わりにステータスコードは 307 になります。
その他のオプションのコンストラクタ引数については、 HttpResponse を参照してください。
この読み取り専用の属性は、レスポンスがリダイレクトするURLを表しています (Location レスポンスヘッダに相当します)。
HttpResponseRedirect に似ていますが、 "found" リダイレクト（ステータスコード 302）ではなく恒久的リダイレクト（HTTP ステータスコード 301）を返します。 preserve_request=True の場合、レスポンスのステータスコードは 308 になります。
コンストラクタは引数を取らず、このレスポンスにはコンテンツを追加すべきではありません。これを使用して、ページがユーザーの最後のリクエスト以降に変更されていないことを指定します(ステータスコード304)。
\nHttpResponse と似ていますが、ステータスコードとして 400 を使用します。
HttpResponse と似ていますが、404 ステータスコードを使用します。
HttpResponse と似ていますが、403 ステータスコードを使用します。
HttpResponse と似ていますが、ステータスコード 405 を使用します。コンストラクタへの最初の引数は必須です: 許可されているメソッドのリスト (例: ['GET', 'POST'])。
HttpResponse と似ていますが、410 ステータスコードを使用します。
HttpResponse と似ていますが、ステータスコードとして 500 を使用します。
If you find yourself needing a response class that Django doesn't provide, you\ncan create it with the help of http.HTTPStatus. For example:
from http import HTTPStatus\nfrom django.http import HttpResponse\n\n\nclass HttpResponseNoContent(HttpResponse):\n status_code = HTTPStatus.NO_CONTENT\nJsonResponse オブジェクトLink to this heading#HttpResponse のサブクラスで、JSONエンコードされたレスポンスを作成するのに役立ちます。このクラスは、いくつかの違いを除き、その基底クラスからほとんどの動作を継承しています:
デフォルトの Content-Type ヘッダーは application/json に設定されています。
最初のパラメーター data は、dict インスタンスであるべきです。safe パラメーターが False に設定されている場合 (下記参照)、これはどんな JSON シリアライズ可能オブジェクトでも可能です。
encoder のデフォルトは django.core.serializers.json.DjangoJSONEncoder で、このエンコーダーがデータのシリアライズに使用されます。このシリアライザについての詳細は、JSON のシリアライズ を参照してください。
safe ブールパラメータのデフォルト値は True です。もし False に設定されている場合、任意のオブジェクトをシリアライズのために渡すことができます（そうでなければ、 dict インスタンスのみが許可されます）。safe が True であり、非 dict オブジェクトが第一引数として渡された場合、 TypeError が発生します。
json_dumps_params パラメーターは、レスポンス生成に使用される json.dumps() 呼び出しに渡すキーワード引数の辞書です。
一般的な使用方法は以下のようになります:
\n>>> from django.http import JsonResponse\n>>> response = JsonResponse({"foo": "bar"})\n>>> response.content\nb'{"foo": "bar"}'\ndict 以外のオブジェクトをシリアライズする場合、 safe パラメータを False に設定する必要があります:
>>> response = JsonResponse([1, 2, 3], safe=False)\nsafe=False を指定しなかった場合、TypeError が発生します。
dict オブジェクトに基づいた API は、より拡張性が高く、柔軟性があり、前方互換性の維持が容易になります。したがって、JSON エンコードされたレスポンスでは非 dict オブジェクトの使用は避けるべきです。
異なるJSONエンコーダークラスを使用する必要がある場合は、コンストラクターメソッドに encoder パラメータを渡すことができます。
>>> response = JsonResponse(data, encoder=MyJSONEncoder)\nStreamingHttpResponse オブジェクトLink to this heading#StreamingHttpResponse クラスは、Djangoからブラウザへのレスポンスをストリーミングするために使用されます。
WSGI 下での StreamingHttpResponse の使用例としては、レスポンスの生成に時間がかかりすぎる場合やメモリを大量に使用する場合にコンテンツをストリーミングすることが挙げられます。例えば、大きなCSVファイルを生成する場合 に役立ちます。
しかしながら、これを行う際にはパフォーマンスを考慮する必要があります。WSGIの下でのDjangoは、短期間のリクエストのために設計されています。ストリーミングレスポンスは、レスポンスの全期間にわたってワーカープロセスを占有します。これにより、パフォーマンスが低下する可能性があります。
\n一般的に、ストリーミングレスポンスに頼るのではなく、リクエスト/レスポンスサイクルの外で高コストのタスクを行うほうが良いです。
\nしかし、ASGI の下で提供される場合、StreamingHttpResponse はI/Oを待っている間に他のリクエストが提供されるのを妨げる必要はありません。これにより、ストリーミングコンテンツのための長時間生存するリクエストや、ロングポーリングやサーバー送信イベントといったパターンの実装の可能性が開かれます。
ASGI環境下であっても、StreamingHttpResponse は、クライアントにデータを転送する前に全内容がイテレートされることが絶対に必要な状況でのみ使用すべきです。コンテンツにアクセスできないため、多くのミドルウェアが正常に機能しません。例えば、ストリーミングレスポンスには ETag や Content-Length ヘッダを生成することができません。
StreamingHttpResponse は、若干異なるAPIを特徴とするため、HttpResponse のサブクラスではありません。しかし、以下に挙げる顕著な違いを除いて、ほぼ同一です。
コンテンツとしてバイト文字列、memoryview、または文字列を生成するイテレータを渡すべきです。WSGI下で提供する場合、これは同期イテレータであるべきです。ASGI下で提供する場合、これは非同期イテレータであるべきです。
その内容にアクセスするには、レスポンスオブジェクト自体をイテレートする必要があります。これはクライアントにレスポンスが返されたときのみ発生すべきです。自分でレスポンスをイテレートすべきではありません。
\nWSGIでは、レスポンスは同期的にイテレートされます。ASGIでは、レスポンスは非同期的にイテレートされます。(これが、イテレータのタイプが使用しているプロトコルと一致しなければならない理由です。)
\nクラッシュを回避するため、間違ったイテレータのタイプは、イテレート中に正しいタイプにマッピングされ、警告が発生します。ただし、これを行うにはイテレータを完全に消費する必要があり、これは全く StreamingHttpResponse を使用する目的を果たしません。
これは content 属性を持ちません。代わりに streaming_content 属性があります。これはミドルウェアでレスポンスのイテラブルをラップするために使用できますが、消費されるべきではありません。
レスポンスオブジェクトを反復処理する必要があるため、 text 属性を持ちません。
ファイルライクオブジェクトの tell() や write() メソッドは使用できません。これらを使用すると例外が発生します。
HttpResponse と StreamingHttpResponse は、共通の基底クラス HttpResponseBase を持っています。
レスポンス内容のイテレータ。 バイト文字列は HttpResponse.charset に従ってエンコードされます。
レスポンスの HTTP ステータスコード 。
\nreason_phrase が明示的にセットされていない限り、コンストラクタの外で status_code の値を変更すると reason_phrase の値も変更されます。
レスポンスの HTTP reason フレーズです。これは HTTP 標準の デフォルトの reason フレーズを使用します。
\nreason_phrase が明示的に設定されていない場合、 status_code の値に基づいて決定されます。
これは常に True です。
StreamingHttpResponse.streaming_content が非同期イテレータであるかどうかを示す真偽値です。
これは、 StreamingHttpResponse.streaming_content をラップする必要があるミドルウェアにとって便利です。
クライアントがストリーミングレスポンス中に切断されると、Django はレスポンスを処理しているコルーチンをキャンセルします。リソースの手動クリーンアップを行いたい場合は、asyncio.CancelledError をキャッチして行うことができます:
async def streaming_response():\n try:\n # Do some work here\n async for chunk in my_streaming_iterator():\n yield chunk\n except asyncio.CancelledError:\n # Handle disconnect\n ...\n raise\n\n\nasync def my_streaming_view(request):\n return StreamingHttpResponse(streaming_response())\nこの例は、レスポンスがストリーミングされている間にクライアントの切断をどのように処理するかを示しているだけです。ビュー内で StreamingHttpResponse オブジェクトを返す前に長時間実行される操作を行う場合は、ビュー自体で 切断を処理する 必要があるかもしれません。
FileResponse オブジェクトLink to this heading#FileResponse はバイナリファイルに最適化された StreamingHttpResponse のサブクラスです。もし WSGI サーバーが提供していれば wsgi.file_wrapper を使用し、そうでない場合はファイルを小さなチャンクでストリーミングします。
as_attachment=True だと、Content-Disposition ヘッダーが attachment に設定され、ブラウザにファイルをダウンロードするように要求します。それ以外の場合は、ファイル名が利用可能な場合のみ、値が inline （ブラウザのデフォルト値）の Content-Disposition ヘッダーが設定されます。
もし open_file に名前がない、または open_file の名前が適切でない場合は、filename パラメータを使用してカスタムファイル名を提供してください。io.BytesIO のようなファイルライクオブジェクトを渡す場合、それを FileResponse に渡す前に seek() を行うのはあなたの仕事です。
open_file の内容から推測できる場合、 Content-Length ヘッダーは自動的に設定されます。
Content-Type ヘッダーは、filename や open_file の名前から推測できる場合には自動的に設定されます。
FileResponse は、例えば以下のようにバイナリモードで開かれたファイルのような、バイナリー内容を持つあらゆるファイルライクオブジェクトを受け付けます。
>>> from django.http import FileResponse\n>>> response = FileResponse(open("myfile.png", "rb"))\nファイルは自動的に閉じられるため、コンテキストマネージャーで開かないでください。
\n\nこのメソッドはレスポンス初期化中に自動的に呼び出され、open_file に応じてさまざまなヘッダー (Content-Length、Content-Type、および Content-Disposition) を設定します。
HttpResponseBase クラスLink to this heading#HttpResponseBase クラスは、Django のすべてのレスポンスに共通です。直接レスポンスを作成するために使用すべきではありませんが、型チェックの際に役立つことがあります。