Django は、システムを通じてステータスを渡すために、リクエストとレスポンスのオブジェクトを使います。
\nあるページがリクエストされたとき、Django はリクエストに関するメタデータを含んだ HttpRequest オブジェクトを生成します。それから Django は HttpRequest をビュー関数の最初の関数として渡し、適切なビューを読み込みます。あらゆるビューは HttpResponse オブジェクトを返す必要があります。
このドキュメントでは、HttpRequest と HttpResponse オブジェクトの API を説明しています。これは django.http モジュールにて定義されています。
HttpRequest オブジェクトLink to this heading#特に記載がない限り、全ての属性は読み取り専用だと考えてください。
\nリクエストのスキームを表す文字列です (通常は http か https)。
バイト文字列で表された生の HTTP リクエストの body です。この値は、バイナリの画像データや XML の payload など、伝統的なの HTML フォームとは異なる方法でデータを処理する時に便利です。伝統的なフォームのデータを処理するばあいは、HttpRequest.POST を使用してください。
ファイルライクなインターフェイルを用いて HttpRequest のデータを読み込むこともできます。詳しくは HttpRequest.read() をご覧ください。
リクエストされたページへのフルパスを表す文字列です。スキーマやドメインは含みません。
\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+.
An 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"
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.
\nExample: "https://example.com/music/bands/the_beatles/?print=true"
Returns 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.
For example:
\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#In an HttpRequest object, the GET and\nPOST attributes are instances of django.http.QueryDict,\na dictionary-like class customized to deal with multiple values for the same\nkey. This is necessary because some HTML form elements, notably\n<select multiple>, pass multiple values for the same key.
The QueryDicts at request.POST and request.GET will be immutable\nwhen accessed in a normal request/response cycle. To get a mutable version you\nneed to use QueryDict.copy().
QueryDict はディクショナリのサブクラスなので、標準的なディクショナリのメソッドを全て実装しています。当てはまらないのはおおむね以下の通りです。
QueryDictに基づいて QueryDict オブジェクトをインスタンス化します。
>>> QueryDict('a=1&a=2&c=3')\n<QueryDict: {'a': ['1', '2'], 'c': ['3']}>\nquery_string が渡されなかった場合は、QueryDict 空となります (何のキーや値も持ちません)。
Most QueryDicts you encounter, and in particular those at\nrequest.POST and request.GET, will be immutable. If you are\ninstantiating one yourself, you can make it mutable by passing\nmutable=True to its __init__().
Strings for setting both keys and values will be converted from encoding\nto str. If encoding is not set, it defaults to\nDEFAULT_CHARSET.
Creates a new QueryDict with keys from iterable and each value\nequal to value. For example:
>>> QueryDict.fromkeys(['a', 'a', 'b'], value='val')\n<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>\nReturns the value for the given key. If the key has more than one value,\nit returns the last value. Raises\ndjango.utils.datastructures.MultiValueDictKeyError if the key does not\nexist. (This is a subclass of Python's standard KeyError, so you can\nstick to catching KeyError.)
Sets the given key to [value] (a list whose single element is\nvalue). Note that this, as other dictionary functions that have side\neffects, can only be called on a mutable QueryDict (such as one that\nwas created via QueryDict.copy()).
Returns True if the given key is set. This lets you do, e.g., if "foo"\nin request.GET.
Uses the same logic as __getitem__(), with a hook for returning a\ndefault value if the key doesn't exist.
Like dict.setdefault(), except it uses __setitem__() internally.
Takes either a QueryDict or a dictionary. Like dict.update(),\nexcept it appends to the current dictionary items rather than replacing\nthem. For example:
>>> 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']\nIn addition, QueryDict has the following methods:
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 モジュール内に存在します。
一般的な使い方は、HttpResponse コンストラクタに、文字列として、ページの内容を引き渡すことです:
>>> 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 をファイルライクなオブジェクトとして使うことができます:
>>> 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 should be an iterator or a string. If it's an\niterator, it should return strings, and those strings will be\njoined together to form the content of the response. If it is not\nan iterator or a string, it will be converted to a string when\naccessed.
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 the DEFAULT_CONTENT_TYPE and\nDEFAULT_CHARSET settings, by default: "text/html; charset=utf-8".
status is the HTTP status code for the response.
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 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\nheader. It is not part of the RFC 2109 standard for cookies,\nand it isn't honored consistently by all browsers. However,\nwhen it is honored, it can be a useful way to mitigate the\nrisk of a client-side script from accessing the protected cookie\ndata.
\nLike 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 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.
JsonResponse 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 strings 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 strings representing the content.
\nレスポンスの 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 optimized\nfor binary files. It uses wsgi.file_wrapper if provided by the wsgi server,\notherwise it streams the file out in small chunks.
FileResponse expects a 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.
\n