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

revision-up-to:	17812 (1.4)

簡単な概要¶

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

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

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

HttpRequest オブジェクト¶

class HttpRequest¶

属性¶

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

HttpRequest.body¶

リリースノートを参照してください

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

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

リリースノートを参照してください

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 を使います)。この属性を変更すれば、フォームデータにアクセスする際に使われるエンコーディングを指定できます。一度エンコーディングを変更すると、変更後に (GET や POST の) 属性へのアクセスはすべて新しい 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_LENGTH と CONTENT_TYPE の例外を含め、上に示されたように、リクエストのどの HTTP ヘッダも、すべての文字を大文字に変換し、すべてのハイフンをアンダーバーに置き換え、名前に HTTP_ のプレフィックスを付加して META のキーに変換されます。よって、例えば、 X-Bender というヘッダは META で HTTP_X_BENDER のキーに割り当てられます。

HttpRequest.user¶

現在ログインしているユーザを表す django.models.auth.models.User オブジェクトです。ユーザが現在ログインしていない場合には、 user は django.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_NAME と SERVER_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() の値を利用する CommonMiddleware や CsrfViewMiddleware のような他のミドルウェアの前に置かなければなりません。

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"

HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)¶

リリースノートを参照してください

署名付きクッキーのクッキーの値を返すか、署名が有効でない場合は 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__()¶

リリースノートを参照してください

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

QueryDict インスタンスは、 copy() を作らないかぎり変更できません。これは、 request.POST や request.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 のリスト型を返します。キーに対応する値がなく、デフォルトの値が与えられていなければ、空のリストを返します。このメソッドは、デフォルトの値がリストでない場合を除き、確実に何らかのリストを返します。

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()¶

リリースノートを参照してください

(キー, リスト) の表現に対し、 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'

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']

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

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

HttpResponse.__setitem__(header, value)¶: ヘッダ名と値を設定します。 header と value は文字列にせねばなりません。

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

HttpResponse.__getitem__(header)¶: 指定のヘッダ名に対応する値を返します。大小文字を区別しません。

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

HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)¶

リリースノートを参照してください

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

リリースノートを参照してください

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

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

max_age には秒数または None (デフォルト値) を指定します。デフォルト値の場合、クッキーはクライアントのブラウザのセッションの間だけ持続します。 expires が明示されていない場合、 expires は計算されます。
expires には "Wdy, DD-Mon-YY HH:MM:SS GMT" の形式の文字列か UTC での datetime.datetime オブジェクトを指定します。 expires が datetime オブジェクトの場合、 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 の一部ではなく、全てのブラウザによって常に守られません。しかし守られた場合、これはクライアントサイドスクリプトが、保護されたクッキーのデータにアクセスする危険を緩和する有用な方法です。

HttpResponse.set_signed_cookie(key, value='', salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)¶: リリースノートを参照してください

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

HttpResponse.delete_cookie(key, path='/', domain=None)¶

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

cookie の動作原理上、 path と domain を set_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 メソッドは有効なレスポンスオブジェクトを返さなければなりません。

Django 1.4 documentation

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

簡単な概要¶

HttpRequest オブジェクト¶

属性¶

メソッド¶

UploadedFile オブジェクト¶

属性¶

メソッド¶

QueryDict オブジェクト¶

メソッド¶

HttpResponse オブジェクト¶

使いかた¶

文字列を渡す¶

イテレータを渡す¶

ヘッダ情報をセットする¶

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

属性¶

メソッド¶

HttpResponse のサブクラス¶

Table Of Contents

前後のページ

現在のページ:

This Page

Last update: