Django uses request and response objects to pass state through the system.
\nWhen a page is requested, Django creates an HttpRequest object that\ncontains metadata about the request. Then Django loads the appropriate view,\npassing the HttpRequest as the first argument to the view function.\nEach view is responsible for returning an HttpResponse object.
This document explains the APIs for HttpRequest and\nHttpResponse objects, which are defined in the django.http\nmodule.
HttpRequest objectsLink to this heading#All attributes should be considered read-only, unless stated otherwise.
\nA string representing the scheme of the request (http or https\nusually).
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.
A string representing the full path to the requested page, not including\nthe scheme, domain, or query string.
\nExample: "/music/bands/the_beatles/"
Under some web server configurations, the portion of the URL after the\nhost name is split up into a script prefix portion and a path info\nportion. The path_info attribute always contains the path info portion\nof the path, no matter what web server is being used. Using this instead\nof path can make your code easier to move between\ntest and deployment servers.
For example, if the WSGIScriptAlias for your application is set to\n"/minfo", then path might be "/minfo/music/bands/the_beatles/"\nand path_info would be "/music/bands/the_beatles/".
A string representing the HTTP method used in the request. This is\nguaranteed to be uppercase. For example:
\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.
A string representing the MIME type of the request, parsed from the\nCONTENT_TYPE header.
A dictionary of key/value parameters included in the CONTENT_TYPE\nheader.
A dictionary-like object containing all given HTTP GET parameters. See the\nQueryDict documentation below.
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 does not include file-upload information. See FILES.
A dictionary containing all cookies. Keys and values are strings.
\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 Managing files 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.
A dictionary containing all available HTTP headers. Available headers\ndepend on the client and server, but here are some examples:
\nCONTENT_LENGTH – The length of the request body (as a string).
CONTENT_TYPE – The MIME type of the request body.
HTTP_ACCEPT – Acceptable content types for the response.
HTTP_ACCEPT_ENCODING – Acceptable encodings for the response.
HTTP_ACCEPT_LANGUAGE – Acceptable languages for the response.
HTTP_HOST – The HTTP Host header sent by the client.
HTTP_REFERER – The referring page, if any.
HTTP_USER_AGENT – The client’s user-agent string.
QUERY_STRING – The query string, as a single (unparsed) string.
REMOTE_ADDR – The IP address of the client.
REMOTE_HOST – The hostname of the client.
REMOTE_USER – The user authenticated by the web server, if any.
REQUEST_METHOD – A string such as "GET" or "POST".
SERVER_NAME – The hostname of the server.
SERVER_PORT – The port of the server (as a string).
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 doesn’t set these attributes itself but makes use of them if set by your\napplication.
\nThe url template tag will use its value as the current_app\nargument to reverse().
This will be used as the root URLconf for the current request, overriding\nthe ROOT_URLCONF setting. See\nHow Django processes a request for details.
urlconf can be set to None to revert any changes made by previous\nmiddleware and return to using the ROOT_URLCONF.
This will be used instead of DEFAULT_EXCEPTION_REPORTER_FILTER\nfor the current request. See Rapporti di errore personalizzati for details.
This will be used instead of DEFAULT_EXCEPTION_REPORTER for the\ncurrent request. See Rapporti di errore personalizzati for details.
Some of the middleware included in Django’s contrib apps set attributes on the\nrequest. If you don’t see the attribute on a request, be sure the appropriate\nmiddleware class is listed in MIDDLEWARE.
From the SessionMiddleware: A\nreadable and writable, dictionary-like object that represents the current\nsession.
From the CurrentSiteMiddleware:\nAn instance of Site or\nRequestSite as returned by\nget_current_site()\nrepresenting the 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.\nThe auser() method does the same thing but can be used from async\ncontexts.
From the AuthenticationMiddleware:\nCoroutine. Returns an instance of AUTH_USER_MODEL representing\nthe currently logged-in user. If the user isn’t currently logged in,\nauser will return an instance of\nAnonymousUser. This is similar to the\nuser attribute but it works in async contexts.
Returns 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"
Raises django.core.exceptions.DisallowedHost if the host is not in\nALLOWED_HOSTS or the domain name is invalid according to\nRFC 1034/1035.
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.
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")\nKeyError: 'nonexistent-cookie'\n>>> request.get_signed_cookie("nonexistent-cookie", False)\nFalse\n>>> request.get_signed_cookie("cookie-that-was-tampered-with")\nBadSignature: ...\n>>> request.get_signed_cookie("name", max_age=60)\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 Accept header matches the mime_type\nargument:
>>> request.accepts("text/html")\nTrue\nMost browsers send Accept: */* by default, so this would return\nTrue for all content types. Setting an explicit Accept header in\nAPI requests can be useful for returning a different content type for those\nconsumers only. See Content negotiation example of using\naccepts() to return different content to API consumers.
If a response varies depending on the content of the Accept header and\nyou are using some form of caching like Django’s cache middleware, you should decorate the view with\nvary_on_headers('Accept') 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\n\nfor element in ET.iterparse(request):\n process(element)\nQueryDict objectsLink 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 implements all the standard dictionary methods because it’s\na subclass of dictionary. Exceptions are outlined here:
Instantiates a QueryDict object based on query_string.
>>> QueryDict("a=1&a=2&c=3")\n<QueryDict: {'a': ['1', '2'], 'c': ['3']}>\nIf query_string is not passed in, the resulting QueryDict will be\nempty (it will have no keys or values).
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 default is None. It’s guaranteed to\nreturn a list unless the default value provided isn’t a list.
Sets 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 objectsLink 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.
The HttpResponse class lives in the django.http module.
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."))\nBut if you want to add content incrementally, you can use response as a\nfile-like object:
>>> response = HttpResponse()\n>>> response.write("<p>Here's the text of the web page.</p>")\n>>> response.write("<p>Here's another paragraph.</p>")\nFinally, you can pass HttpResponse an iterator rather than strings.\nHttpResponse will consume the iterator immediately, store its content as a\nstring, and discard it. Objects with a close() method such as files and\ngenerators are immediately closed.
If you need the response to be streamed from the iterator to the client, you\nmust use the StreamingHttpResponse class instead.
To set or remove a header field in your response, use\nHttpResponse.headers:
>>> response = HttpResponse()\n>>> response.headers["Age"] = 120\n>>> del response.headers["Age"]\nYou can also manipulate headers by treating your response like a dictionary:
\n>>> response = HttpResponse()\n>>> response["Age"] = 120\n>>> del response["Age"]\nThis proxies to HttpResponse.headers, and is the original interface offered\nby HttpResponse.
When using this interface, unlike a dictionary, del doesn’t raise\nKeyError if the header field doesn’t exist.
You can also set headers on instantiation:
\n>>> response = HttpResponse(headers={"Age": 120})\nFor 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, set the\nContent-Type and Content-Disposition headers. For example, this is how\nyou might return a Microsoft Excel spreadsheet:
>>> response = HttpResponse(\n... my_data,\n... headers={\n... "Content-Type": "application/vnd.ms-excel",\n... "Content-Disposition": 'attachment; filename="foo.xls"',\n... },\n... )\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.
\nA http.cookies.SimpleCookie object holding the cookies included\nin the response.
A case insensitive, dict-like object that provides an interface to all\nHTTP headers on the response, except a Set-Cookie header. See\nSetting header fields and HttpResponse.cookies.
A string denoting the charset in which the response will be encoded. If not\ngiven at HttpResponse instantiation time, it will be extracted from\ncontent_type and if that is unsuccessful, the\nDEFAULT_CHARSET setting will be used.
The HTTP status code for the response.
\nUnless reason_phrase is explicitly set, modifying the value of\nstatus_code outside the constructor will also modify the value of\nreason_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 False.
This attribute exists so middleware can treat streaming responses\ndifferently from regular responses.
\nTrue if the response has been closed.
Instantiates an HttpResponse object with the given page content,\ncontent type, and headers.
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\nresponse. You can use Python’s http.HTTPStatus for meaningful\naliases, such 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.
headers is a dict of HTTP headers for the response.
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 the value for the given header, or an alternate if the header\ndoesn’t exist.
Returns True or False based on a case-insensitive check for a\nheader with the given name.
Acts like dict.items() for HTTP headers on the response.
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 timedelta object, an integer\nnumber of seconds, or None (default) if the cookie should last only\nas long as the client’s browser session. If expires is not specified,\nit 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.
Use samesite='None' (string) to explicitly state that this cookie is\nsent with all same-site and cross-site requests.
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\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.
Note that an API based on dict objects is more extensible, flexible, and\nmakes it easier to maintain forwards compatibility. Therefore, you should avoid\nusing non-dict objects in JSON-encoded response.
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.
An example usage of StreamingHttpResponse under WSGI is streaming\ncontent when generating the response would take too long or uses too much\nmemory. For instance, it’s useful for generating large CSV files.
There are performance considerations when doing this, though. Django, under\nWSGI, is designed for short-lived requests. Streaming responses will tie a\nworker process for the entire duration of the response. This may result in poor\nperformance.
\nGenerally speaking, you would perform expensive tasks outside of the\nrequest-response cycle, rather than resorting to a streamed response.
\nWhen serving under ASGI, however, a StreamingHttpResponse need not\nstop other requests from being served whilst waiting for I/O. This opens up\nthe possibility of long-lived requests for streaming content and implementing\npatterns such as long-polling, and server-sent events.
Even under ASGI note, StreamingHttpResponse should only be used in\nsituations where it is absolutely required that the whole content isn’t\niterated before transferring the data to the client. Because the content can’t\nbe accessed, many middleware can’t function normally. For example the ETag\nand Content-Length headers can’t be generated for streaming responses.
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, memoryview,\nor strings as content. When serving under WSGI, this should be a sync\niterator. When serving under ASGI, then it should be an async iterator.
You cannot access its content, except by iterating the response object\nitself. This should only occur when the response is returned to the client:\nyou should not iterate the response yourself.
\nUnder WSGI the response will be iterated synchronously. Under ASGI the\nresponse will be iterated asynchronously. (This is why the iterator type must\nmatch the protocol you’re using.)
\nTo avoid a crash, an incorrect iterator type will be mapped to the correct\ntype during iteration, and a warning will be raised, but in order to do this\nthe iterator must be fully-consumed, which defeats the purpose of using a\nStreamingHttpResponse at all.
It has no content attribute. Instead, it has a\nstreaming_content attribute. This can be used\nin middleware to wrap the response iterable, but should not be consumed.
You cannot use the file-like object tell() or write() methods.\nDoing so will raise an exception.
The HttpResponseBase base class is common between\nHttpResponse and StreamingHttpResponse.
An iterator of the response content, bytestring encoded according to\nHttpResponse.charset.
The HTTP status code for the response.
\nUnless reason_phrase is explicitly set, modifying the value of\nstatus_code outside the constructor will also modify the value of\nreason_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.
Boolean indicating whether StreamingHttpResponse.streaming_content\nis an asynchronous iterator or not.
This is useful for middleware needing to wrap\nStreamingHttpResponse.streaming_content.
If the client disconnects during a streaming response, Django will cancel the\ncoroutine that is handling the response. If you want to clean up resources\nmanually, you can do so by catching the asyncio.CancelledError:
async def streaming_response():\n try:\n # Do some work here\n async for chunk in my_streaming_iterator():\n yield chunk\n except asyncio.CancelledError:\n # Handle disconnect\n ...\n raise\n\n\nasync def my_streaming_view(request):\n return StreamingHttpResponse(streaming_response())\nThis example only shows how to handle client disconnection while the response\nis streaming. If you perform long-running operations in your view before\nreturning the StreamingHttpResponse object, then you may also want to\nhandle disconnections in the view itself.
FileResponse objectsLink to this heading#FileResponse is a subclass of StreamingHttpResponse\noptimized for binary files. It uses wsgi.file_wrapper if provided by the wsgi\nserver, 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 header is automatically set when it can be guessed\nfrom the content of open_file.
The Content-Type header is automatically set when it can be guessed\nfrom the filename, or the name 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.
\n\nThis method is automatically called during the response initialization and\nset various headers (Content-Length, Content-Type, and\nContent-Disposition) depending on open_file.
HttpResponseBase classLink to this heading#The HttpResponseBase class is common to all Django responses.\nIt should not be used to create responses directly, but it can be\nuseful for type-checking.