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

簡単な概要¶

Django は、システムを通じてステータスを渡すために、リクエストとレスポンスのオブジェクトを使います。

あるページがリクエストされたとき、Django はリクエストに関するメタデータを含んだ HttpRequest オブジェクトを生成します。それから Django は HttpRequest をビュー関数の最初の関数として渡し、適切なビューを読み込みます。あらゆるビューは HttpResponse オブジェクトを返す必要があります。

このドキュメントでは、HttpRequest と HttpResponse オブジェクトの API を説明しています。これは django.http モジュールにて定義されています。

`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¶

要求されたページへのフルパスを表す文字列であり、scheme、ドメイン、クエリ文字列は含みません。

例: "/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 で、これは DEFAULT_CHARSET 設定が使用されることを意味します）。この属性に書き込むことで、フォームデータにアクセスする際に使用されるエンコーディングを変更できます。その後の属性アクセス（GET や POST からの読み取りなど）は、新しい encoding 値を使用します。フォームデータが DEFAULT_CHARSET エンコーディングでないことがわかっている場合に便利です。

HttpRequest.content_type¶: リクエストの MIME タイプを表す文字列です。CONTENT_TYPE から識別されます。

HttpRequest.content_params¶: CONTENT_TYPE ヘッダに含まれる、キーと値のパラーメータのディクショナリです。

HttpRequest.GET¶: 渡された HTTP GET パラメータを含む、ディクショナリライクのオブジェクトです。後述の QueryDict のドキュメントを参照してください。

HttpRequest.POST¶

リクエストにフォームデータが含まれている場合に、すべての与えられた HTTP POST パラメータを含む辞書のようなオブジェクト。以下の QueryDict ドキュメントを参照してください。リクエストにポストされた生のデータや非フォームデータにアクセスする必要がある場合は、代わりに HttpRequest.body 属性を通じてアクセスしてください。

POST メソッドでフォームデータが含まれていない場合に、空の POST ディクショナリを備えたリクエストが発生する可能性があります。そのため、POST メソッドの使用を確認するために if request.POST を使用すべきではありません。代わりに、 if request.method == "POST" を使用してください (HttpRequest.method を参照)。

POST には file-upload の情報が含まれ ません 。詳しくは FILES を参照してください。

HttpRequest.COOKIES¶: すべてのクッキーが格納されたディクショナリです。キーと値は文字列です。

HttpRequest.FILES¶

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 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プレフィックス付きヘッダーにアクセスするより簡単な方法です。

HttpRequest.headers[ソース]¶

リクエストからHTTPプリフィックスヘッダー全体 (Content-Length と Content-Type を含む) にアクセスを提供する、大文字小文字を区別しない辞書風オブジェクトです。

各ヘッダーの名前は、表示される際にタイトルケース (例: 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¶: The url template tag will use its value as the current_app argument to reverse().

HttpRequest.urlconf¶

この値は、現在のリクエストに対する root URLconf として使用され、設定の ROOT_URLCONF を上書きします。詳しくは Django のリクエスト処理を参照してください。

urlconf は None に設定することで、それまでにミドルウェアで行われた変更を取り消し、元の ROOT_URLCONF を使用するようにできます。

HttpRequest.exception_reporter_filter¶: これは、現在のリクエストに対して DEFAULT_EXCEPTION_REPORTER_FILTER の代わりに使用されます。詳細については、カスタムエラーレポートを参照してください。

HttpRequest.exception_reporter_class¶: これは、現在のリクエストに対して DEFAULT_EXCEPTION_REPORTER の代わりに使用されます。詳細についてはカスタムエラーレポートを参照してください。

ミドルウェアが設定する属性¶

Django の contrib アプリなどのミドルウェアの一部は、リクエストに属性を設定します。もし、リクエストに属性が設定されていない場合は、MIDDLEWARE リスト中に適切なミドルウェアが含まれているかを確認してください。

HttpRequest.session¶: SessionMiddleware は、現在のセッションを表す、読み書き可能でディクショナリライクなオブジェクトを設定します。

HttpRequest.site¶: From the CurrentSiteMiddleware: An instance of Site or RequestSite as returned by get_current_site() representing the current site.

HttpRequest.user¶

AuthenticationMiddleware から: 現在ログインしているユーザーを表す AUTH_USER_MODEL のインスタンスです。ユーザーが現在ログインしていない場合、 user は AnonymousUser のインスタンスに設定されます。 is_authenticated を使用して、それらを区別できます。例えば、こうです:

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

auser() メソッドは同じ機能を提供しますが、非同期コンテキストから使用できます。

メソッド¶

HttpRequest.auser()¶: AuthenticationMiddleware から: コルーチン。現在ログインしているユーザーを表す AUTH_USER_MODEL のインスタンスを返します。もしユーザーが現在ログインしていない場合、auser は AnonymousUser のインスタンスを返します。これは user 属性に似ていますが、非同期コンテキストでも機能します。

HttpRequest.get_host()[ソース]¶

リクエストの発信元ホストを返します。この情報は、順番に 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 を発生させます。

注釈

The get_host() method fails when the host is behind multiple proxies. One solution is to use middleware to rewrite the proxy headers, as in the following example:

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