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

revision-up-to:17812 (1.4)

簡単な概要

Django は、システム全体にわたって、リクエストとレスポンスオブジェクトを使っ て処理状態を受け渡します。

あるページへのリクエストを受け取ると、Django は HttpRequest オブジェクトを生成します。このオブジェク トにはリクエストのメタデータが入っています。次に Django は適切なビューをロー ドして、 HttpRequest をビュー関数の最初の引数に渡しま す。各ビューは HttpResponse オブジェクトを返さねばな りません。

このドキュメントでは HttpRequest および HttpResponse オブジェクトの API について説明します。

HttpRequest オブジェクト

class HttpRequest

属性

session 以外の属性は全て読み出し専用です。

HttpRequest.body
Django 1.4 で変更されました: リリースノートを参照してください

Django 1.4 以前では、HttpRequest.bodyHttpRequest.raw_post_data でした.

生の HTTP リクエストのバイト文字列です。これは従来の HTML フォームと 異なる、バイナリ画像や XML ペイロードのデータを処理するのに便利です。 従来のフォームのデータを処理するためには HttpRequest.POST を 使って下さい。

Django 1.3 で新たに登場しました: リリースノートを参照してください

HttpRequest をファイルのようなインターフェースで読むことも出来ます。 後述の HttpRequest.read() も参照して下さい。

HttpRequest.path

リクエストしているページのフルパスを表す、ドメインを含まない文字列です。

例: "/music/bands/the_beatles/"

HttpRequest.path_info

いくつかの Web サーバーの設定において、ホストネーム以降の URL の一部が スクリプトプレフィックスの部分と PATH_INFO の部分に分割されます。 ( 例えば、これが発生するのは、 django.root オプションを Apache と mod_python で Django を動かす で使っている場合 ) path_info 属性には、どの Web サーバーが使われている かに関わらず、常にパスの PATH_INFO の部分が入ります。 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 を使います)。この属性を変更すれば、フォーム データにアクセスする際に使われるエンコーディングを指定できます。一度エ ンコーディングを変更すると、変更後に (GETPOST の) 属性への アクセスはすべて新しい encoding の値に従って行われます。フォームデー タが DEFAULT_CHARSET 以外の特定のエンコーディングと分かって いる場合に便利です。

HttpRequest.GET

全ての HTTP GET パラメタが入った辞書ライクなオブジェクトです。後述の QueryDict も参照してください。

HttpRequest.POST

全ての HTTP POST パラメタが入った辞書ライクなオブジェクトです。後述の QueryDict も参照してください。

フォームを POST HTTP メソッドで要求し、その際に何らフォームデータを伴わ ないような場合には、リクエストが POST で送られていながらも POST 辞 書が空になることがあります。従って、リクエストが POST メソッドであるか どうかを調べるために if request.POST を使うべきではありません。代わ りに if request.method == "POST" を使ってください (上参照)。

POST にはファイルアップロードに関する情報は 入っていない ので注意 してください。 FILES を参照してください。

HttpRequest.REQUEST

便宜的な辞書オブジェクトで、 POST パラメタをまず検索してから、次に GET パラメタを検索します。 PHP の $_REQUEST にインスパイアされ た機能です。

例えば、 GET = {"name": "john"}POST = {"age": '34'} の場合、 REQUEST["name"]"john" になり、 REQUEST["age"]"34" になります。

通常は GET および POST を使うように強く勧めます。その方が明示的 だからです。

HttpRequest.COOKIES

全てのクッキーが入った標準の Python 辞書オブジェクトです。キーと値は文 字列です。

HttpRequest.FILES

アップロードされた全てのファイルが入っている辞書ライクオブジェクトです。 FILES の各キーは <input type="file" name="" />name に対応しています。 FILES の各値は後述の UploadedFile オブジ ェクトです.

詳しくは ファイルの管理 を参照してください。

FILES にデータが入るのは、リクエストが POST であり、かつリクエ ストをポストした <form>enctype="multipart/form-data がある 場合だけです。それ以外の場合、 FILES は空の辞書ライクオブジェクトに なります。

HttpRequest.META

標準の Python 辞書オブジェクトで、利用できる全ての HTTP ヘッダが入って います。利用可能なヘッダはクライアントとサーバごとに違いますが、例えば 以下のようなヘッダを利用できます:

  • CONTENT_LENGTH – リクエストのボディの長さ(文字列)です。
  • CONTENT_TYPE – リクエストのボディの MIME タイプです。
  • HTTP_ACCEPT_ENCODING – レスポンスとして利用可能な文字コードです。
  • HTTP_ACCEPT_LANGUAGE – レスポンスとして利用可能な言語です。
  • HTTP_HOST – クライアントによって送信された HTTP Host ヘッダです。
  • HTTP_REFERER – リクエスト対象のページを参照しているページが ある場合、そのページの URL です。
  • HTTP_USER_AGENT – クライアントのユーザエージェントの文字列です。
  • QUERY_STRING – パース前の単一のクエリ文字列です。
  • REMOTE_ADDR – クライアントの IP アドレスです。
  • REMOTE_HOST – クライアントのホスト名です。
  • REMOTE_USER – Web サーバーによって認証されたユーザがある場合、 そのユーザです。
  • REQUEST_METHOD"GET""POST" のような文字列です。
  • SERVER_NAME – サーバのホスト名です。
  • SERVER_PORT – サーバのポート番号(文字列)です。

CONTENT_LENGTHCONTENT_TYPE の例外を含め、上に示されたように、 リクエストのどの HTTP ヘッダも、すべての文字を大文字に変換し、すべての ハイフンをアンダーバーに置き換え、 名前に HTTP_ のプレフィックスを 付加して META のキーに変換されます。よって、例えば、 X-Bender というヘッダは METAHTTP_X_BENDER のキーに割り当てられます。

HttpRequest.user

現在ログインしているユーザを表す django.models.auth.models.User オブ ジェクトです。ユーザが現在ログインしていない場合には、 userdjango.contrib.auth.models.AnonymousUser のインスタンスになります。 is_authenticated() を使うと、これら二種類のユーザを区別できます:

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

user を利用できるのは、 インストールした Django で AuthenticationMiddleware を有効にした場合だけです。詳しくは Django でのユーザ認証 を参照してください。

HttpRequest.session

読み書き可能な辞書ライクオブジェクトで、現在のセッションを表現しています。 この辞書はインストールされている Django でセッションが有効な場合にのみ 利用できます。 詳しくは セッションのドキュメント を 参照してください。

HttpRequest.urlconf

Django 自体はこの属性を設定しませんが、他のコード(自作のミドルウェアな ど)でこの属性を設定した場合、Djangoはその値を ROOT_URLCONF の代わりにルート URLconf モジュール名として使います。 詳しくは 「 Django のリクエスト処理 」を参照してください。

メソッド

HttpRequest.get_host()

HTTP_X_FORWARDED_HOST ヘッダ(USE_X_FORWARDED_HOST が 有効化されている場合)と HTTP_HOST ヘッダを順に調べて、リクエストの 送信元を返します。クライアントがそれらの値を提供していない場合は PEP 3333 に従って、SERVER_NAMESERVER_PORT の組み合わせを 返します。

例: "127.0.0.1:8000"

Note

ホストが複数のプロキシを通しているとき、 get_host() は失敗します。一つの解決策は ロキシヘッダを書き換えるミドルウェアを利用することです。 以下に例を示します:

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

    def process_request(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()

このミドルウェアは get_host() の値を利用する CommonMiddlewareCsrfViewMiddleware のような 他のミドルウェアの前に置かなければなりません。

HttpRequest.get_full_path()

path と、そのあとに続くクエリ文字列があれば返します。

例: "/music/bands/the_beatles/?print=true"

HttpRequest.build_absolute_uri(location)

location の絶対 URI を計算して返します。引数 location を省略する と、 location の値として request.get_full_path() を使います。

location の値がすでに絶対 URI であれば、値を変更しません。そうでない 場合、リクエスト中のサーバに関する変数を使って URI を構築します。

例: "http://example.com/music/bands/the_beatles/?print=true"

Django 1.4 で新たに登場しました: リリースノートを参照してください

署名付きクッキーのクッキーの値を返すか、署名が有効でない場合は BadSignature 例外を発生します。 default 引数を与えた場合は、例外は抑制され、代わりにデフォルトの 値が返されます。

オプションの salt 引数はシークレットキーへのブルートフォース攻撃に 対する追加の防御を与えるために利用されます。引数が与えられた場合、 max_age 引数は、 max_age 秒よりクッキーが古くないかを確認する ために、クッキーの署名されたタイムスタンプに対してチェックされます。

例:

>>> 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('non-existing-cookie')
...
KeyError: 'non-existing-cookie'
>>> request.get_signed_cookie('non-existing-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()

リクエストがセキュアである、すなわち HTTPS を介したリクエストのときに True を返します。

HttpRequest.is_ajax()

リクエストが XMLHttpRequest である場合には True に設定されます。 リクエストが XMLHttpRequest であるかどうかは、 HTTP_X_REQUESTED_WITH ヘッダに文字列 XMLHttpRequest があるかどう かで判別します。このヘッダは、ほとんどのモダンな主要 JavaScript ライブ ラリでサポートされています。 ブラウザ側で XMLHttpRequest を呼び出す独自のコードを書いている場合、 is_ajax() を正しく機能させたいなら、 HTTP_X_REQUESTED_WITH ヘッ ダを適切に設定してください。

HttpRequest.read(size=None)
HttpRequest.readline()
HttpRequest.readlines()
HttpRequest.xreadlines()
HttpRequest.__iter__()
Django 1.3 で新たに登場しました: リリースノートを参照してください

HTTPRequest のインスタンスからファイルのようなインターフェースで 読むメソッドです。このメソッドはやってくるリクエストをストリーミング のやり方で消費することを可能にします。一般的な利用事例は大きな XML ペイロードを、反復パーサでメモリ上にすべての XML ツリーを 構築することなく、処理することです。

この標準的なインターフェースを使って、直接 ElementTree のような XML パーサに HTTPRequest インスタンスを渡すことが出来ます:

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

UploadedFile オブジェクト

class UploadedFile

属性

UploadedFile.name

アップロードされたファイルの名前。

UploadedFile.size

バイト単位でのアップロードされたファイルのサイズ。

メソッド

UploadedFile.chunks(chunk_size=None)

データの連続したチャンクを生成するジェネレータを返します。

UploadedFile.read(num_bytes=None)

引数のバイト数分ファイルを読みます。

QueryDict オブジェクト

HttpRequest オブジェクト内では、 GETPOST 属性は django.http.QueryDict のインスタンスです。 QueryDict は辞書ライクなクラスで、同じキーに対して複 数の値を取り得るようにカスタマイズされています。これは、 HTML のフォーム要 素には、例えば <select multiple="multiple"> のように、同じキーに対して 複数の値を渡すものがあるからです。

QueryDict インスタンスは、 copy() を作らないかぎ り変更できません。これは、 request.POSTrequest.GET の属性を直接 変更できないということです。

メソッド

QueryDict は辞書型のサブクラスなので、全ての標準的な 辞書型のメソッドを実装しています。ただし、以下の点が異なります:

QueryDict.__getitem__(key)

指定のキーに対する値を返します。一つのキーに複数の値が存在する場合、 __getitem__() はリストの末尾の値を返します。キーに対応する値がなけ れば、 django.utils.datastructures.MultiValueDictKeyError を送出 します。 (この例外は KeyError のサブクラスなので、 KeyError` を見張っていれば捕捉できます。)

QueryDict.__setitem__(key, value)

指定のキーに対する値を [value] (value という値が一つだけ入った リスト) にします。副作用をともなう他の関数と同じく、このメソッドを呼び 出せるのは (copy() を使って生成したオブジェクトのような) 変更可能な QueryDict だけです。

QueryDict.__contains__(key)

指定のキーが設定されている場合に True を返します。 if "foo" in request.GET のような書き方を実現します。

QueryDict.get(key, default)

上の __getitem__() と同じロジックですが、キーに対応する値がないとき にデフォルト値を返すフックがあります。

QueryDict.setdefault(key, default)

標準の辞書型の setdefault() と同じですが、内部的に __setitem__() を使います。

QueryDict.update(other_dict)

QueryDict または標準の辞書型を引数にとります。標 準の辞書型の update() メソッドと同じですが、現在の値を置き換えるの ではなく、現在の値のリストに 追加 します。例えば:

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

標準の辞書型の items()`() メソッドと同じですが、 __getitem__() と同じ、最後の値を返すロジックを使います。例えば:

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

標準の辞書型の iteritems() によく似ています。 QueryDict.items() と同じく、 QueryDict.__getitem__() で最後の値を返します。

QueryDict.iterlists()

QueryDict.iteritems() に似ていますが、各辞書のメンバの値を全て リストとして返します。

QueryDict.values()

values() – 標準の辞書型の values() メソッドと同じですが、 __getitem__() と同じ、最後の値を返すロジックを使います。例えば:

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

QueryDict.values() と同じですが、イテレータです。

加えて、 QueryDict には以下のメソッドがあります:

QueryDict.copy()

Python 標準ライブラリの copy.deepcopy() を使ってオブジェクトのコピー を生成して返します。コピーは変更可能になり、値を変更できます。

QueryDict.getlist(key, default)

要求されたキーに対して、 Python のリスト型を返します。キーに対応する値 がなく、デフォルトの値が与えられていなければ、空のリストを返します。 このメソッドは、デフォルトの値がリストでない場合を除き、確実に何らかの リストを返します。

Django 1.4 で変更されました: default パラメタが追加されました。
QueryDict.setlist(key, list_)

キーに対して list_ を対応づけます (__setitem__() と違います)。

QueryDict.appendlist(key, item)

キーに関連づけられている内部的なリストに要素を追加します。

QueryDict.setlistdefault(key, default_list)

setdefault に似ていますが、単一の値ではなく値のリストを引数にとりま す。

QueryDict.lists()

動作は items() に似ていますが、全ての値をリストで返します。例え ば:

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[(u'a', [u'1', u'2', u'3'])]
QueryDict.dict()
Django 1.4 で新たに登場しました: リリースノートを参照してください

(キー, リスト) の表現に対し、 dict は (キー, アイテム)を持ちます。 アイテムとなるのはリストのうち、ひとつの要素で、 QueryDict.__getitem__() と同じロジックを用いています。

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

データをクエリ文字列形式にフォーマットした文字列を返します。例えば:

>>> q = QueryDict('a=2&b=3&b=5')
>>> q.urlencode()
'a=2&b=3&b=5'
Django 1.3 で変更されました: safe パラメタが追加されました。

オプションで、urlencodeにエンコードする必要がない文字列を渡すことが 出来ます。例えば:

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

HttpResponse オブジェクト

class HttpResponse

Django によって自動生成される HttpRequest オブジェク トとは対象的に、 HttpResponse オブジェクトは自分で生 成せねばなりません。ビューを書くときにはいつでも、 HttpResponse インスタンスを生成して、値を設定し、戻り 値として返さねばなりません。

HttpResponse クラスは django.http モジュールで 定義されています。

使いかた

文字列を渡す

HttpResponse の典型的な使い方は、ページの内容を文字列 としてコンストラクタに渡すというものです:

>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.", content_type="text/plain")

コンテンツを累積的に追加していきたい場合には、 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 を初期化した場合、 HttpResponse インスタンスは ファイルライクオブジェクトとして扱えず、ファイルライクオブジェクトと して操作すると Exception を送出します。

ヘッダ情報をセットする

レスポンスのヘッダをセットしたり削除したりするには、レスポンスを辞書の ように扱います:

>>> response = HttpResponse()
>>> response['Cache-Control'] = 'no-cache'
>>> del response['Cache-Control']

辞書と異なり、 もしヘッダーが存在しない場合も、delKeyError を 発生させません。

HTTP ヘッダには改行を含めてはなりません。改行文字 (CR や LF) の入ったヘッダ をセットしようとすると、 BadHeaderError を送出します。

レスポンスをブラウザにファイルアタッチメントとして扱わせる

レスポンスをブラウザにファイルアタッチメントとして扱わせるには、 content_type 引数を使い、 Content-Disposition ヘッダをセットして ください。例えば、 Microsoft Excel のスプレッドシートを返すには、以下の ようにします:

>>> response = HttpResponse(my_data, content_type='application/vnd.ms-excel')
>>> response['Content-Disposition'] = 'attachment; filename=foo.xls'

Content-Disposition ヘッダの利用は Django 固有の仕様ではありませんが、 記法を忘れやすいのでここに示しておきます。

属性

HttpResponse.content

コンテンツを表現する文字列表現です。必要に応じて Unicode オブジェクト からエンコードされます。

HttpResponse.status_code

レスポンスの HTTP Status code です。

メソッド

HttpResponse.__init__(content='', mimetype=None, status=200, content_type=DEFAULT_CONTENT_TYPE)

指定のページコンテンツ (文字列) と MIME タイプで HttpResponse オブジェクトをインスタンス化します。 DEFAULT_CONTENT_TYPE'text/html' です。

content はイタレータまたは文字列でなければなりません。イタレータに する場合、イタレータは文字列を返さねばなりません。イテレータを指定した 場合、レスポンスの内容はイテレータの返す文字列を結合して生成されます。 イタレータまたは文字列でない場合、アクセスした際に文字列に変換される でしょう。

status はレスポンスの HTTP 状態コード です。

content_typemimetype の別名にすぎません。以前、このパラメタ には mimetype という名前しかありませんでしたが、実際のところ、この パラメタに指定する値は HTTP の Content-Type ヘッダに入る内容であり、 MIME タイプ仕様にはない文字セットエンコーディングの指定を含んでいました。 そこで、 mimetype が指定されている (None でない) 場合にはその値 を使い、それ以外の場合には content_type を使うように変更しました。 どちらのパラメタも省略すると、 DEFAULT_CONTENT_TYPE 設定を使 います。

HttpResponse.__setitem__(header, value)

ヘッダ名と値を設定します。 headervalue は文字列にせねばなり ません。

HttpResponse.__delitem__(header)

指定の名前のヘッダを削除します。ヘッダが存在しなければ、暗黙のうちに失 敗します。大小文字を区別しません。

HttpResponse.__getitem__(header)

指定のヘッダ名に対応する値を返します。大小文字を区別しません。

HttpResponse.has_header(header)

大小文字を区別せずに指定の名前のヘッダがあるか調べ、 True または False を返します。

Django 1.3 で変更されました: リリースノートを参照してください

expiresdatetime.datetime オブジェクトを指定すると、 max_age が自動的に計算されます。 httponly 引数も追加されました。

Django 1.4 で変更されました: リリースノートを参照してください

httponly のデフォルトの値が False から True に変わりました。

クッキーを設定します。パラメタは Python 標準ライブラリの Cookie.Morsel オブジェクトと同じ形式です。

  • max_age には秒数または None (デフォルト値) を指定します。 デフォルト値の場合、クッキーはクライアントのブラウザのセッションの 間だけ持続します。 expires が明示されていない場合、 expires は計算されます。

  • expires には "Wdy, DD-Mon-YY HH:MM:SS GMT" の形式の文字列か UTC での datetime.datetime オブジェクトを指定します。 expiresdatetime オブジェクトの場合、 max_age は 自動的に計算されます。

  • 別のドメインのクッキー (cross-domain cookie) を設定したい場合には、 domain を使います。例えば、 domain=".lawrence.com" にする と、 www.lawrence.com, blogs.lawrence.com, calendars.lawrence.com といったサイトでだけ読めるようになります。それ以外の場合、クッキー はクッキーを設定したドメインでしか読めません。

  • クライアントサイドの JavaScript がクッキーへアクセスすることを 妨げたい場合、 httponly=True を使います。

    HTTPOnly は HTTP レスポンスヘッダの Set-Cookie に含まれるフラグです。 これはクッキーの標準の RFC 2109 の一部ではなく、全てのブラウザに よって常に守られません。しかし守られた場合、これはクライアントサイド スクリプトが、保護されたクッキーのデータにアクセスする危険を緩和す る有用な方法です。

Django 1.4 で新たに登場しました: リリースノートを参照してください

set_cookie() と同様のメソッドです。しかし、 セットする前に 暗号による署名 を行って下さい。 HttpRequest.get_signed_cookie() と併せて使って下さい。オプションで 鍵の強化のために salt 引数を使うことが出来ますが、対応する HttpRequest.get_signed_cookie() の呼び出しでも、 salt 引数を 渡す必要があります。

指定のキーに対するクッキーを削除します。キーが存在しなければ、暗黙のう ちに失敗します。

cookie の動作原理上、 pathdomainset_cookie() に指定 した値と同じにしないと、クッキーを削除できなくなります。

HttpResponse.write(content)

HttpResponse インスタンスをファイルライクオブジェ クトのように扱うためのメソッドです。

HttpResponse.flush()

HttpResponse インスタンスをファイルライクオブジェ クトのように扱うためのメソッドです。

HttpResponse.tell()

HttpResponse インスタンスをファイルライクオブジェ クトのように扱うためのメソッドです。

HttpResponse のサブクラス

Django には、様々なタイプの HTTP レスポンスを扱うための HttpResponse のサブクラスがあります。これらのサブクラ スは HttpResponse と同じく django.http モジュー ルにあります。

class HttpResponseRedirect

コンストラクタはリダイレクト先のパスを示す引数を一つだけ取ります。リダ イレクト先は完全指定の URL (例えば "http://www.yahoo.com/search/") でも、ドメイン名のない絶対 URL ( "/search/") でもかまいません。この レスポンスオブジェクトは HTTP 状態コード 302 を返します。

class HttpResponsePermanentRedirect

HttpResponseRedirect と同じですが、”found” リダイレクト (HTTP 状態 コード 302) ではなく永続リダイレクト (状態コード 301) を使います。

class HttpResponseNotModified

コンストラクタは引数をとりません。ユーザが最後にリクエストしたときから ページが変更されていないこと (状態コード 304) を知らせるために使います。

class HttpResponseBadRequest

HttpResponse と同じように振舞いますが、状態コード 400 を使います。

class HttpResponseNotFound

HttpResponse と同じですが、状態コード 404 を使い ます。

class HttpResponseForbidden

HttpResponse と同じですが、状態コード 403 を使い ます。

class HttpResponseNotAllowed

HttpResponse と同じですが、状態コード 405 を使い ます。許可されている HTTP メソッドのリスト (例えば ['GET', 'POST']) を必須の引数としてとります。

class HttpResponseGone

HttpResponse と同じですが、状態コード 410 を使い ます。

class HttpResponseServerError

HttpResponse と同じですが、状態コード 500 を使います。

Note

もし、 HttpResponse のカスタムサブクラスが render メソッドを 実装している場合は、 Django はそれを SimpleTemplateResponse を真似たもの として扱うでしょう、また render メソッドは有効なレスポンスオブジェクトを 返さなければなりません。