Django は、システムを通じてステータスを渡すために、リクエストとレスポンスのオブジェクトを使います。
\nあるページがリクエストされたとき、Django はリクエストに関するメタデータを含んだ HttpRequest オブジェクトを生成します。それから Django は HttpRequest をビュー関数の最初の関数として渡し、適切なビューを読み込みます。あらゆるビューは HttpResponse オブジェクトを返す必要があります。
このドキュメントでは、HttpRequest と HttpResponse オブジェクトの API を説明しています。これは django.http モジュールにて定義されています。
HttpRequest オブジェクトLink to this heading#特に記載がない限り、全ての属性は読み取り専用だと考えてください。
\nリクエストのスキームを表す文字列です (通常は http か https)。
The raw HTTP request body as a bytestring. This is useful for processing\ndata in different ways than conventional HTML forms: binary images,\nXML payload etc. For processing conventional form data, use\nHttpRequest.POST.
You can also read from an HttpRequest using a file-like interface with\nHttpRequest.read() or HttpRequest.readline(). Accessing\nthe body attribute after reading the request with either of these I/O\nstream methods will produce a RawPostDataException.
リクエストされたページへのフルパスを表す文字列です。スキーマやドメインは含みません。
\n例: "/music/bands/the_beatles/"
ウェブサーバーの設定によっては、ホスト名の後ろの URL の部分が、スクリプト接頭辞部分とパス情報部分に分離されることがあります。path_info 属性には、どんなウェブサーバを使用していても常に、パスのパス情報部分が含まれます。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()\nA string representing the current encoding used to decode form submission\ndata (or None, which means the DEFAULT_CHARSET setting is\nused). You can write to this attribute to change the encoding used when\naccessing the form data. Any subsequent attribute accesses (such as reading\nfrom GET or POST) will use the new encoding value.\nUseful if you know the form data is not in the DEFAULT_CHARSET\nencoding.
リクエストの MIME タイプを表す文字列です。CONTENT_TYPE から識別されます。
CONTENT_TYPE ヘッダに含まれる、キーと値のパラーメータのディクショナリです。
渡された HTTP GET パラメータを含む、ディクショナリライクのオブジェクトです。後述の QueryDict のドキュメントを参照してください。
A dictionary-like object containing all given HTTP POST parameters,\nproviding that the request contains form data. See the\nQueryDict documentation below. If you need to access raw or\nnon-form data posted in the request, access this through the\nHttpRequest.body attribute instead.
It's possible that a request can come in via POST with an empty POST\ndictionary -- if, say, a form is requested via the POST HTTP method but\ndoes not include form data. Therefore, you shouldn't use if request.POST\nto check for use of the POST method; instead, use if request.method ==\n"POST" (see HttpRequest.method).
POST には file-upload の情報が含まれ ません 。詳しくは FILES をご覧ください。
すべてのクッキーが格納されたディクショナリです。キーと値は文字列です。
\nA dictionary-like object containing all uploaded files. Each key in\nFILES is the name from the <input type="file" name="">. Each\nvalue in FILES is an UploadedFile.
See ファイルの管理 for more information.
\nFILES will only contain data if the request method was POST and the\n<form> that posted to the request had enctype="multipart/form-data".\nOtherwise, FILES will be a blank dictionary-like object.
利用できるすべての 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 -- (存在する場合) Web サーバによって認証されたユーザです。
REQUEST_METHOD -- "GET" や "POST" といったです。
SERVER_NAME -- サーバのホスト名です。
SERVER_PORT -- (文字列としての) サーバのポートです。
With the exception of CONTENT_LENGTH and CONTENT_TYPE, as given\nabove, any HTTP headers in the request are converted to META keys by\nconverting all characters to uppercase, replacing any hyphens with\nunderscores and adding an HTTP_ prefix to the name. So, for example, a\nheader called X-Bender would be mapped to the META key\nHTTP_X_BENDER.
Note that runserver strips all headers with underscores in the\nname, so you won't see them in META. This prevents header-spoofing\nbased on ambiguity between underscores and dashes both being normalizing to\nunderscores in WSGI environment variables. It matches the behavior of\nWeb servers like Nginx and Apache 2.4+.
HttpRequest.headers is a simpler way to access all HTTP-prefixed\nheaders, plus CONTENT_LENGTH and CONTENT_TYPE.
A case insensitive, dict-like object that provides access to all\nHTTP-prefixed headers (plus Content-Length and Content-Type) from\nthe request.
The name of each header is stylized with title-casing (e.g. User-Agent)\nwhen it's displayed. You can access headers case-insensitively:
>>> 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)\nFor use in, for example, Django templates, headers can also be looked up\nusing underscores in place of hyphens:
\n{{ request.headers.user_agent }}\nAn instance of ResolverMatch representing the\nresolved URL. This attribute is only set after URL resolving took place,\nwhich means it's available in all views but not in middleware which are\nexecuted before URL resolving takes place (you can use it in\nprocess_view() though).
Django はこれらの属性を自分で設定することはありませんが、アプリケーション側で設定された場合にはその値を利用します。
\nこの値は、現在のリクエストに対する root URLconf として使用され、設定の ROOT_URLCONF を上書きします。詳しくは Django のリクエスト処理 をご覧ください。
urlconf は None に設定することで、それまでにミドルウェアで行われた変更を取り消し、元の ROOT_URLCONF を使用するようにできます。
Django の contrib アプリなどのミドルウェアの一部は、リクエストに属性を設定します。もし、リクエストに属性が設定されていない場合は、MIDDLEWARE リスト中に適切なミドルウェアが含まれているかを確認してください。
SessionMiddleware は、現在のセッションを表す、読み書き可能でディクショナリライクなオブジェクトを設定します。
CurrentSiteMiddleware は、現在のサイトを表す Site または RequestSite のインスタンスを、get_current_site() の返り値で設定します。
From the AuthenticationMiddleware:\nAn instance of AUTH_USER_MODEL representing the currently\nlogged-in user. If the user isn't currently logged in, user will be set\nto an instance of AnonymousUser. You\ncan tell them apart with\nis_authenticated, like so:
if request.user.is_authenticated:\n ... # Do something for logged-in users.\nelse:\n ... # Do something for anonymous users.\nReturns the originating host of the request using information from the\nHTTP_X_FORWARDED_HOST (if USE_X_FORWARDED_HOST is enabled)\nand HTTP_HOST headers, in that order. If they don't provide a value,\nthe method uses a combination of SERVER_NAME and SERVER_PORT as\ndetailed in PEP 3333.
Example: "127.0.0.1:8000"
Returns the originating port of the request using information from the\nHTTP_X_FORWARDED_PORT (if USE_X_FORWARDED_PORT is enabled)\nand SERVER_PORT META variables, in that order.
Returns the path, plus an appended query string, if applicable.
Example: "/music/bands/the_beatles/?print=true"
Like get_full_path(), but uses path_info instead of\npath.
Example: "/minfo/music/bands/the_beatles/?print=true"
Returns the absolute URI form of location. If no location is provided,\nthe location will be set to request.get_full_path().
If the location is already an absolute URI, it will not be altered.\nOtherwise the absolute URI is built using the server variables available in\nthis request. For example:
\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/'\nReturns a cookie value for a signed cookie, or raises a\ndjango.core.signing.BadSignature exception if the signature is\nno longer valid. If you provide the default argument the exception\nwill be suppressed and that default value will be returned instead.
The optional salt argument can be used to provide extra protection\nagainst brute force attacks on your secret key. If supplied, the\nmax_age argument will be checked against the signed timestamp\nattached to the cookie value to ensure the cookie is not older than\nmax_age seconds.
例:
\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')\n...\nKeyError: 'nonexistent-cookie'\n>>> request.get_signed_cookie('nonexistent-cookie', False)\nFalse\n>>> request.get_signed_cookie('cookie-that-was-tampered-with')\n...\nBadSignature: ...\n>>> request.get_signed_cookie('name', max_age=60)\n...\nSignatureExpired: Signature age 1677.3839159 > 60 seconds\n>>> request.get_signed_cookie('name', False, max_age=60)\nFalse\nSee cryptographic signing for more information.
\nReturns True if the request is secure; that is, if it was made with\nHTTPS.
Returns True if the request was made via an XMLHttpRequest, by\nchecking the HTTP_X_REQUESTED_WITH header for the string\n'XMLHttpRequest'. Most modern JavaScript libraries send this header.\nIf you write your own XMLHttpRequest call (on the browser side), you'll\nhave to set this header manually if you want is_ajax() to work.
If a response varies on whether or not it's requested via AJAX and you are\nusing some form of caching like Django's cache middleware, you should decorate the view with\nvary_on_headers('X-Requested-With') so that the responses are\nproperly cached.
Methods implementing a file-like interface for reading from an\nHttpRequest instance. This makes it possible to consume an incoming\nrequest in a streaming fashion. A common use-case would be to process a\nbig XML payload with an iterative parser without constructing a whole\nXML tree in memory.
Given this standard interface, an HttpRequest instance can be\npassed directly to an XML parser such as\nElementTree:
import xml.etree.ElementTree as ET\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 がデフォルトとなります。
イテラブルと value と一致する各値から、新しい QueryDict を作成します。例えば:
>>> QueryDict.fromkeys(['a', 'a', 'b'], value='val')\n<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>\n指定したキーに対する値を返します。キーが複数の値を持つ場合、最後の値を返します。キーが存在しない場合は django.utils.datastructures.MultiValueDictKeyError を発生させます (これは Python の標準的な KeyError サブクラスなので、KeyError をキャッチすることに固執できます)。
指定したキーを [value] (各要素が value のリスト) にセットします。 副作用を持つ他のディクショナリ関数と同様に、編集可能な QueryDict (QueryDict.copy() で作成されたものなど) のみで呼び出し可能です.
指定したキーがセットされている場合 True を返します。例えば if "foo" in request.GET を実行するのと同じです。
__getitem__() と同じロジックを使いますが、キーが存在しない場合のデフォルト値をフックします。
Like dict.setdefault(), except it uses __setitem__() internally.
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'\nLike dict.items(), except this uses the same last-value logic as\n__getitem__() and returns an iterator object instead of a view object.\nFor example:
>>> q = QueryDict('a=1&a=2&a=3')\n>>> list(q.items())\n[('a', '3')]\nLike dict.values(), except this uses the same last-value logic as\n__getitem__() and returns an iterator instead of a view object. For\nexample:
>>> q = QueryDict('a=1&a=2&a=3')\n>>> list(q.values())\n['3']\n加えて、QueryDict は以下のメソッドを持ちます:
Returns a copy of the object using copy.deepcopy(). This copy will\nbe mutable even if the original was not.
Returns a list of the data with the requested key. Returns an empty list if\nthe key doesn't exist and a default value wasn't provided. It's guaranteed\nto return a list unless the default value provided isn't a list.
\nSets the given key to list_ (unlike __setitem__()).
Appends an item to the internal list associated with key.
\nLike setdefault(), except it takes a list of values instead of a\nsingle value.
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'])]\nReturns a list of values for the given key and removes them from the\ndictionary. Raises KeyError if the key does not exist. For example:
>>> q = QueryDict('a=1&a=2&a=3', mutable=True)\n>>> q.pop('a')\n['1', '2', '3']\nRemoves an arbitrary member of the dictionary (since there's no concept\nof ordering), and returns a two value tuple containing the key and a list\nof all values for the key. Raises KeyError when called on an empty\ndictionary. For example:
>>> q = QueryDict('a=1&a=2&a=3', mutable=True)\n>>> q.popitem()\n('a', ['1', '2', '3'])\nReturns a dict representation of QueryDict. For every (key, list)\npair in QueryDict, dict will have (key, item), where item is one\nelement of the list, using the same logic as QueryDict.__getitem__():
>>> q = QueryDict('a=1&a=3&a=5')\n>>> q.dict()\n{'a': '5'}\nReturns a string of the data in query string format. For example:
\n>>> q = QueryDict('a=2&b=3&b=5')\n>>> q.urlencode()\n'a=2&b=3&b=5'\nUse the safe parameter to pass characters which don't require encoding.\nFor example:
>>> q = QueryDict(mutable=True)\n>>> q['next'] = '/a&b/'\n>>> q.urlencode(safe='/')\n'next=/a%26b/'\nHttpResponse オブジェクトLink to this heading#In contrast to HttpRequest objects, which are created automatically by\nDjango, HttpResponse objects are your responsibility. Each view you\nwrite is responsible for instantiating, populating, and returning an\nHttpResponse.
HttpResponse クラスは django.http モジュール内に存在します。
Typical usage is to pass the contents of the page, as a string, bytestring,\nor memoryview, to the HttpResponse constructor:
>>> 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 クラスを使う必要があります。
レスポンス上でヘッダーフィールドをセットしたり削除するためには、ディクショナリのように扱ってください:
\n>>> response = HttpResponse()\n>>> response['Age'] = 120\n>>> del response['Age']\nディクショナリとは異なり、ヘッダーフィールドが存在しないときでも del が KeyError を投げない点に注意してください。
For setting the Cache-Control and Vary header fields, it is recommended\nto use the patch_cache_control() and\npatch_vary_headers() methods from\ndjango.utils.cache, since these fields can have multiple, comma-separated\nvalues. The "patch" methods ensure that other values, e.g. added by a\nmiddleware, are not removed.
HTTP header fields cannot contain newlines. An attempt to set a header field\ncontaining a newline character (CR or LF) will raise BadHeaderError
To tell the browser to treat the response as a file attachment, use the\ncontent_type argument and set the Content-Disposition header. For example,\nthis is how you might return a Microsoft Excel spreadsheet:
>>> response = HttpResponse(my_data, content_type='application/vnd.ms-excel')\n>>> response['Content-Disposition'] = 'attachment; filename="foo.xls"'\nThere's nothing Django-specific about the Content-Disposition header, but\nit's easy to forget the syntax, so we've included it here.
A bytestring representing the content, encoded from a string if necessary.
\n応答がエンコードされる文字セットを示す文字列です。 HttpResponse のインスタンス化の際に指定されなかった場合、content_type から抽出され、もしこれが失敗した場合は、DEFAULT_CHARSET 設定が使用されます。
レスポンスの HTTP status code です。
\nreason_phrase が明示的にセットされていない限り、コンストラクタの外で status_code の値を変更すると``reason_phrase`` の値も変更されます。
The HTTP reason phrase for the response. It uses the HTTP standard's default reason phrases.
\nUnless explicitly set, reason_phrase is determined by the value of\nstatus_code.
これは常に False です。
この属性は、ミドルウェアが通常のレスポンスとは違う形でストリーミングレスポンスを扱えるようにするために存在しています。
\nレスポンスが閉じられた場合、True となります。
Instantiates an HttpResponse object with the given page content and\ncontent type.
content is most commonly an iterator, bytestring, memoryview,\nor string. Other types will be converted to a bytestring by encoding their\nstring representation. Iterators should return strings or bytestrings and\nthose will be joined together to form the content of the response.
content_type is the MIME type optionally completed by a character set\nencoding and is used to fill the HTTP Content-Type header. If not\nspecified, it is formed by 'text/html' and the\nDEFAULT_CHARSET settings, by default:\n"text/html; charset=utf-8".
status is the HTTP status code for the response.\nYou can use Python's http.HTTPStatus for meaningful aliases,\nsuch as HTTPStatus.NO_CONTENT.
reason is the HTTP response phrase. If not provided, a default phrase\nwill be used.
charset is the charset in which the response will be encoded. If not\ngiven it will be extracted from content_type, and if that\nis unsuccessful, the DEFAULT_CHARSET setting will be used.
Sets the given header name to the given value. Both header and\nvalue should be strings.
Deletes the header with the given name. Fails silently if the header\ndoesn't exist. Case-insensitive.
\nReturns the value for the given header name. Case-insensitive.
\nReturns True or False based on a case-insensitive check for a\nheader with the given name.
Sets a header unless it has already been set.
\nSets a cookie. The parameters are the same as in the\nMorsel cookie object in the Python standard library.
max_age should be a number of seconds, or None (default) if\nthe cookie should last only as long as the client's browser session.\nIf expires is not specified, it will be calculated.
expires should either be a string in the format\n"Wdy, DD-Mon-YY HH:MM:SS GMT" or a datetime.datetime object\nin UTC. If expires is a datetime object, the max_age\nwill be calculated.
Use domain if you want to set a cross-domain cookie. For example,\ndomain="example.com" will set a cookie that is readable by the\ndomains www.example.com, blog.example.com, etc. Otherwise, a cookie will\nonly be readable by the domain that set it.
Use secure=True if you want the cookie to be only sent to the server\nwhen a request is made with the https scheme.
Use httponly=True if you want to prevent client-side\nJavaScript from having access to the cookie.
HttpOnly is a flag included in a Set-Cookie HTTP response header. It's\npart of the RFC 6265 standard for cookies\nand can be a useful way to mitigate the risk of a client-side script\naccessing the protected cookie data.
\nUse samesite='Strict' or samesite='Lax' to tell the browser not\nto send this cookie when performing a cross-origin request. SameSite\nisn't supported by all browsers, so it's not a replacement for Django's\nCSRF protection, but rather a defense in depth measure.
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 for added key strength, but\nyou will need to remember to pass it to the corresponding\nHttpRequest.get_signed_cookie() call.
Deletes the cookie with the given key. Fails silently if the key doesn't\nexist.
\nDue to the way cookies work, path and domain should be the same\nvalues you used in set_cookie() -- otherwise the cookie may not be\ndeleted.
This method is called at the end of the request directly by the WSGI\nserver.
\nThis method makes an HttpResponse instance a file-like object.
This method makes an HttpResponse instance a file-like object.
This method makes an HttpResponse instance a file-like object.
Returns the value of HttpResponse.content. This method makes\nan HttpResponse instance a stream-like object.
Always False. This method makes an HttpResponse instance a\nstream-like object.
Always False. This method makes an HttpResponse instance a\nstream-like object.
Always True. This method makes an HttpResponse instance a\nstream-like object.
Writes a list of lines to the response. Line separators are not added. This\nmethod makes an HttpResponse instance a stream-like object.
HttpResponse subclassesLink to this heading#Django includes a number of HttpResponse subclasses that handle different\ntypes of HTTP responses. Like HttpResponse, these subclasses live in\ndjango.http.
The first argument to the constructor is required -- the path to redirect\nto. This can be a fully qualified URL\n(e.g. 'https://www.yahoo.com/search/'), an absolute path with no domain\n(e.g. '/search/'), or even a relative path (e.g. 'search/'). In that\nlast case, the client browser will reconstruct the full URL itself\naccording to the current path. See HttpResponse for other optional\nconstructor arguments. Note that this returns an HTTP status code 302.
This read-only attribute represents the URL the response will redirect\nto (equivalent to the Location response header).
Like HttpResponseRedirect, but it returns a permanent redirect\n(HTTP status code 301) instead of a "found" redirect (status code 302).
The constructor doesn't take any arguments and no content should be added\nto this response. Use this to designate that a page hasn't been modified\nsince the user's last request (status code 304).
\nActs just like HttpResponse but uses a 400 status code.
Acts just like HttpResponse but uses a 404 status code.
Acts just like HttpResponse but uses a 403 status code.
Like HttpResponse, but uses a 405 status code. The first argument\nto the constructor is required: a list of permitted methods (e.g.\n['GET', 'POST']).
Acts just like HttpResponse but uses a 410 status code.
Acts just like HttpResponse but uses a 500 status code.
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\nclass HttpResponseNoContent(HttpResponse):\n status_code = HTTPStatus.NO_CONTENT\nJsonResponse objectsLink to this heading#An HttpResponse subclass that helps to create a JSON-encoded\nresponse. It inherits most behavior from its superclass with a couple\ndifferences:
Its default Content-Type header is set to application/json.
The first parameter, data, should be a dict instance. If the\nsafe parameter is set to False (see below) it can be any\nJSON-serializable object.
The encoder, which defaults to\ndjango.core.serializers.json.DjangoJSONEncoder, will be used to\nserialize the data. See JSON serialization for more details about this serializer.
The safe boolean parameter defaults to True. If it's set to\nFalse, any object can be passed for serialization (otherwise only\ndict instances are allowed). If safe is True and a non-dict\nobject is passed as the first argument, a TypeError will be raised.
The json_dumps_params parameter is a dictionary of keyword arguments\nto pass to the json.dumps() call used to generate the response.
Typical usage could look like:
\n>>> from django.http import JsonResponse\n>>> response = JsonResponse({'foo': 'bar'})\n>>> response.content\nb'{"foo": "bar"}'\nIn order to serialize objects other than dict you must set the safe\nparameter to False:
>>> response = JsonResponse([1, 2, 3], safe=False)\nWithout passing safe=False, a TypeError will be raised.
If you need to use a different JSON encoder class you can pass the encoder\nparameter to the constructor method:
>>> response = JsonResponse(data, encoder=MyJSONEncoder)\nStreamingHttpResponse objectsLink to this heading#The StreamingHttpResponse class is used to stream a response from\nDjango to the browser. You might want to do this if generating the response\ntakes too long or uses too much memory. For instance, it's useful for\ngenerating large CSV files.
The StreamingHttpResponse is not a subclass of HttpResponse,\nbecause it features a slightly different API. However, it is almost identical,\nwith the following notable differences:
It should be given an iterator that yields bytestrings as content.
You cannot access its content, except by iterating the response object\nitself. This should only occur when the response is returned to the client.
It has no content attribute. Instead, it has a\nstreaming_content attribute.
You cannot use the file-like object tell() or write() methods.\nDoing so will raise an exception.
StreamingHttpResponse should only be used in situations where it is\nabsolutely required that the whole content isn't iterated before transferring\nthe data to the client. Because the content can't be accessed, many\nmiddleware can't function normally. For example the ETag and\nContent-Length headers can't be generated for streaming responses.
An iterator of the response content, bytestring encoded according to\nHttpResponse.charset.
レスポンスの HTTP status code です。
\nreason_phrase が明示的にセットされていない限り、コンストラクタの外で status_code の値を変更すると``reason_phrase`` の値も変更されます。
The HTTP reason phrase for the response. It uses the HTTP standard's default reason phrases.
\nUnless explicitly set, reason_phrase is determined by the value of\nstatus_code.
This is always True.
FileResponse objectsLink to this heading#FileResponse is a subclass of StreamingHttpResponse\noptimized for binary files. It uses wsgi.file_wrapper if provided by the\nwsgi server, otherwise it streams the file out in small chunks.
If as_attachment=True, the Content-Disposition header is set to\nattachment, which asks the browser to offer the file to the user as a\ndownload. Otherwise, a Content-Disposition header with a value of\ninline (the browser default) will be set only if a filename is\navailable.
If open_file doesn't have a name or if the name of open_file isn't\nappropriate, provide a custom file name using the filename parameter.\nNote that if you pass a file-like object like io.BytesIO, it's your\ntask to seek() it before passing it to FileResponse.
The Content-Length and Content-Type headers are automatically set\nwhen they can be guessed from contents of open_file.
FileResponse accepts any file-like object with binary content, for example\na file open in binary mode like so:
>>> from django.http import FileResponse\n>>> response = FileResponse(open('myfile.png', 'rb'))\nThe file will be closed automatically, so don't open it with a context manager.
\nThis method is automatically called during the response initialization and\nset various headers (Content-Length, Content-Type, and\nContent-Disposition) depending on open_file.