リクエストオブジェクトとレスポンスオブジェクト—Djangoドキュメント

提供：Dev Guides
< DjangoDjango/docs/3.2.x/ref/request-response
移動先:案内、検索

リクエストオブジェクトとレスポンスオブジェクト

クイック概要

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メソッドを表す文字列。 これは大文字であることが保証されています。 例えば：

if request.method == 'GET':
    do_something()
elif request.method == 'POST':
    do_something_else()
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）が表示されたとき。 大文字と小文字を区別せずにヘッダーにアクセスできます。

>>> request.headers
{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}

>>> 'User-Agent' in request.headers
True
>>> 'user-agent' in request.headers
True

>>> request.headers['User-Agent']
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers['user-agent']
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

>>> request.headers.get('User-Agent')
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers.get('user-agent')
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

たとえば、Djangoテンプレートで使用する場合、ヘッダーはハイフンの代わりにアンダースコアを使用して検索することもできます。

{{ request.headers.user_agent }}
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 でそれらを区別できます。

if request.user.is_authenticated:
    ... # Do something for logged-in users.
else:
    ... # Do something for anonymous users.


メソッド

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つの解決策は、次の例のように、ミドルウェアを使用してプロキシヘッダーを書き換えることです。

class MultipleProxyMiddleware:
    FORWARDED_FOR_FIELDS = [
        'HTTP_X_FORWARDED_FOR',
        'HTTP_X_FORWARDED_HOST',
        'HTTP_X_FORWARDED_SERVER',
    ]

    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        """
        Rewrites the proxy headers so that only the most
        recent proxy is used.
        """
        for field in self.FORWARDED_FOR_FIELDS:
            if field in request.META:
                if ',' in request.META[field]:
                    parts = request.META[field].split(',')
                    request.META[field] = parts[-1].strip()
        return self.get_response(request)

このミドルウェアは、 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は、このリクエストで使用可能なサーバー変数を使用して構築されます。 例えば：

>>> request.build_absolute_uri()
'https://example.com/music/bands/the_beatles/?print=true'
>>> request.build_absolute_uri('/bands/')
'https://example.com/bands/'
>>> request.build_absolute_uri('https://example2.com/bands/')
'https://example2.com/bands/'

ノート

同じサイトで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値に添付された署名付きタイムスタンプと照合されます。

例えば：

>>> request.get_signed_cookie('name')
'Tony'
>>> request.get_signed_cookie('name', salt='name-salt')
'Tony' # assuming cookie was set using the same salt
>>> request.get_signed_cookie('nonexistent-cookie')
...
KeyError: 'nonexistent-cookie'
>>> request.get_signed_cookie('nonexistent-cookie', False)
False
>>> request.get_signed_cookie('cookie-that-was-tampered-with')
...
BadSignature: ...
>>> request.get_signed_cookie('name', max_age=60)
...
SignatureExpired: Signature age 1677.3839159 > 60 seconds
>>> request.get_signed_cookie('name', False, max_age=60)
False

詳細については、暗号署名を参照してください。

HttpRequest.is_secure()
リクエストが安全な場合はTrueを返します。 つまり、HTTPSで作成された場合です。
HttpRequest.accepts(mime_type)

バージョン3.1の新機能。

リクエストAcceptヘッダーがmime_type引数と一致する場合、Trueを返します。

>>> request.accepts('text/html')
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パーサーに直接渡すことができます。

import xml.etree.ElementTree as ET
for element in ET.iterparse(request):
    process(element)


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オブジェクトをインスタンス化します。

>>> QueryDict('a=1&a=2&c=3')
<QueryDict: {'a': ['1', '2'], 'c': ['3']}>

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.fromkeys(['a', 'a', 'b'], value='val')
<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>
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()と同様ですが、現在の辞書アイテムを置き換えるのではなく、がに追加する点が異なります。 例えば：

>>> q = QueryDict('a=1', mutable=True)
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # returns the last
'2'
QueryDict.items()

dict.items()と同様ですが、これは __ getitem __（）と同じ最終値ロジックを使用し、ビューオブジェクトの代わりにイテレータオブジェクトを返します。 例えば：

>>> q = QueryDict('a=1&a=2&a=3')
>>> list(q.items())
[('a', '3')]
QueryDict.values()

dict.values()と同様ですが、これは __ getitem __（）と同じ最終値ロジックを使用し、ビューオブジェクトの代わりにイテレーターを返します。 例えば：

>>> q = QueryDict('a=1&a=2&a=3')
>>> list(q.values())
['3']

さらに、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（）と同様ですが、ディクショナリの各メンバーのすべての値がリストとして含まれている点が異なります。 例えば：

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]
QueryDict.pop(key)

指定されたキーの値のリストを返し、それらをディクショナリから削除します。 キーが存在しない場合はKeyErrorを発生させます。 例えば：

>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.pop('a')
['1', '2', '3']
QueryDict.popitem()

ディクショナリの任意のメンバーを削除し（順序付けの概念がないため）、キーを含む2つの値のタプルと、キーのすべての値のリストを返します。 空の辞書で呼び出されると、KeyErrorが発生します。 例えば：

>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.popitem()
('a', ['1', '2', '3'])
QueryDict.dict()

QueryDictのdict表現を返します。 QueryDictのすべての（key、list）ペアに対して、dictには（key、item）があります。ここで、itemは、 QueryDict .__ getitem__と同じロジックを使用して、リストの1つの要素です。 （）：

>>> q = QueryDict('a=1&a=3&a=5')
>>> q.dict()
{'a': '5'}
QueryDict.urlencode(safe=None)

データの文字列をクエリ文字列形式で返します。 例えば：

>>> q = QueryDict('a=2&b=3&b=5')
>>> q.urlencode()
'a=2&b=3&b=5'

safeパラメーターを使用して、エンコードを必要としない文字を渡します。 例えば：

>>> q = QueryDict(mutable=True)
>>> q['next'] = '/a&b/'
>>> q.urlencode(safe='/')
'next=/a%26b/'


HttpResponseオブジェクト

class HttpResponse

Djangoによって自動的に作成される HttpRequest オブジェクトとは対照的に、 HttpResponse オブジェクトはユーザーの責任です。 作成する各ビューは、 HttpResponse のインスタンス化、入力、および返送を担当します。

HttpResponse クラスは django.http モジュールにあります。

使用法

文字列を渡す

一般的な使用法は、ページのコンテンツを文字列、バイト文字列、またはmemoryviewとして HttpResponse コンストラクターに渡すことです。 

>>> from django.http import HttpResponse
>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.", content_type="text/plain")
>>> response = HttpResponse(b'Bytestrings are also accepted.')
>>> response = HttpResponse(memoryview(b'Memoryview as well.'))

ただし、コンテンツを段階的に追加する場合は、responseをファイルのようなオブジェクトとして使用できます。 

>>> response = HttpResponse()
>>> response.write("<p>Here's the text of the Web page.</p>")
>>> response.write("<p>Here's another paragraph.</p>")

イテレータの受け渡し

最後に、文字列ではなくHttpResponseイテレータを渡すことができます。 HttpResponseはイテレータをすぐに消費し、その内容を文字列として保存して破棄します。 ファイルやジェネレーターなど、close()メソッドを持つオブジェクトはすぐに閉じられます。

イテレータからクライアントに応答をストリーミングする必要がある場合は、代わりに StreamingHttpResponse クラスを使用する必要があります。


ヘッダーフィールドの設定

応答のヘッダーフィールドを設定または削除するには、 HttpResponse.headers を使用します。 

>>> response = HttpResponse()
>>> response.headers['Age'] = 120
>>> del response.headers['Age']

応答を辞書のように扱うことで、ヘッダーを操作することもできます。 

>>> response = HttpResponse()
>>> response['Age'] = 120
>>> del response['Age']

これはHttpResponse.headersのプロキシであり、HttpResponseによって提供される元のインターフェイスです。

このインターフェイスを使用する場合、辞書とは異なり、ヘッダーフィールドが存在しない場合、delはKeyErrorを発生させません。

インスタンス化時にヘッダーを設定することもできます。 

>>> response = HttpResponse(headers={'Age': 120})

Cache-ControlおよびVaryヘッダーフィールドを設定するには、 djangoの patch_cache_control（）および patch_vary_headers（）メソッドを使用することをお勧めします.utils.cache 、これらのフィールドは複数のコンマ区切り値を持つことができるため。 「パッチ」メソッドは、他の値を保証します。 ミドルウェアによって追加されたものは削除されません。

HTTPヘッダーフィールドに改行を含めることはできません。 改行文字（CRまたはLF）を含むヘッダーフィールドを設定しようとすると、BadHeaderErrorが発生します。

バージョン3.2で変更： HttpResponse.headers インターフェースが追加されました。

インスタンス化時にヘッダーを設定する機能が追加されました。


応答を添付ファイルとして扱うようにブラウザに指示する

応答を添付ファイルとして扱うようにブラウザに指示するには、Content-TypeおよびContent-Dispositionヘッダーを設定します。 たとえば、MicrosoftExcelスプレッドシートを返す方法は次のとおりです。 

>>> response = HttpResponse(my_data, headers={
...     'Content-Type': 'application/vnd.ms-excel',
...     'Content-Disposition': 'attachment; filename="foo.xls"',
... })

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タイプであり、HTTP Content-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を使用して作成できます。 例えば： 

from http import HTTPStatus
from django.http import HttpResponse

class HttpResponseNoContent(HttpResponse):
    status_code = HTTPStatus.NO_CONTENT

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()呼び出しに渡すキーワード引数の辞書です。

使用法

一般的な使用法は次のようになります。 

>>> from django.http import JsonResponse
>>> response = JsonResponse({'foo': 'bar'})
>>> response.content
b'{"foo": "bar"}'

非辞書オブジェクトのシリアル化

dict以外のオブジェクトをシリアル化するには、safeパラメーターをFalseに設定する必要があります。 

>>> response = JsonResponse([1, 2, 3], safe=False)

safe=Falseを渡さないと、TypeErrorが発生します。

警告

ECMAScript の第5版より前は、JavaScript Arrayコンストラクターをポイズニングすることが可能でした。 このため、Djangoはデフォルトで非dictオブジェクトを JsonResponse コンストラクターに渡すことを許可していません。 ただし、最近のほとんどのブラウザは、この攻撃ベクトルを削除するEcmaScript5を実装しています。 したがって、このセキュリティ対策を無効にすることができます。


デフォルトのJSONエンコーダーの変更

別のJSONエンコーダークラスを使用する必要がある場合は、encoderパラメーターをコンストラクターメソッドに渡すことができます。 

>>> response = JsonResponse(data, encoder=MyJSONEncoder)

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は、バイナリコンテンツを持つファイルのようなオブジェクトを受け入れます。たとえば、次のようにバイナリモードで開いているファイルです。 

>>> from django.http import FileResponse
>>> response = FileResponse(open('myfile.png', 'rb'))

ファイルは自動的に閉じられるため、コンテキストマネージャーで開かないでください。

メソッド

FileResponse.set_headers(open_file)
このメソッドは、応答の初期化中に自動的に呼び出され、open_fileに応じてさまざまなヘッダー（Content-Length、Content-Type、およびContent-Disposition）を設定します。



「https://www.finddevguides.com/index.php?title=Django/docs/3.2.x/ref/request-response&oldid=96243」から取得
Powered by MediaWiki