Django 使用Request 对象和Response 对象在系统间传递状态。
当请求一个页面时,Django会建立一个包含请求元数据的 HttpRequest
对象。 当Django 加载对应的视图时,HttpRequest
对象将作为视图函数的第一个参数。
每个视图会返回一个HttpResponse
对象。
本文档对HttpRequest
和HttpResponse
对象的API 进行说明,这些API 定义在django.http
模块中。
HttpRequest
对象¶所有属性应被视为只读,除非另有说明。
HttpRequest.
scheme
¶一个字符串,表示请求的方案(通常是http
或https
)。
HttpRequest.
body
¶一个字节字符串,表示原始HTTP 请求的正文。 它对于处理非HTML 形式的数据非常有用:二进制图像、XML等。 如果要处理常规的表单数据,应该使用HttpRequest.POST
。
你还可以使用类似文件的接口从HttpRequest
中读取数据。 参见HttpRequest.read()
。
HttpRequest.
path
¶表示请求页面的完整路径的字符串,不包括方案或域。
例如:"/music/bands/the_beatles/"
HttpRequest.
path_info
¶在某些Web 服务器配置下,主机名后的URL 部分被分成脚本前缀部分和路径信息部分。 path_info
属性将始终包含路径信息部分,不论使用的Web 服务器是什么。 使用它代替path
可以让代码在测试和开发环境中更容易地切换。
例如,如果应用的WSGIScriptAlias
设置为"/music/bands/the_beatles/"
,那么当"/minfo"
是"/minfo/music/bands/the_beatles/"
时path_info
将是path
。
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.
content_type
¶表示从CONTENT_TYPE
头解析的请求的MIME类型的字符串。
HttpRequest.
content_params
¶包含在CONTENT_TYPE
标题中的键/值参数字典。
HttpRequest.
POST
¶一个包含所有给定的HTTP POST参数的类字典对象,提供了包含表单数据的请求。 详情请参考下面的QueryDict
文档。 如果需要访问请求中的原始或非表单数据,可以使用HttpRequest.body
属性。
POST请求可能带有一个空的POST
字典 — 如果通过HTTP POST方法请求一个表单但是没有包含表单数据。 所以,你不应该使用if request.POST
来检查使用的是否是POST方法;请使用if request.method == "POST"
(参见HttpRequest.method
)。
POST
不包含文件上传信息。 参见FILES
。
HttpRequest.
COOKIES
¶包含所有Cookie的字典。 键和值都为字符串。
HttpRequest.
FILES
¶一个类似于字典的对象,包含所有上传的文件。 FILES
中的每个键为<input type="file" name="" />
中的name
。 FILES
中的每个值是一个UploadedFile
。
更多信息参见管理文件。
如果请求方法是POST且请求的<form>
带有enctype="multipart/form-data"
,那么FILES
将只包含数据。
否则,FILES
将为一个空的类似于字典的对象。
HttpRequest.
META
¶包含所有可用HTTP标头的字典。 具体的头部信息取决于客户端和服务器,下面是一些示例:
CONTENT_LENGTH
—— 请求的正文的长度(是一个字符串)。CONTENT_TYPE
—— 请求的正文的MIME 类型。HTTP_ACCEPT
—— 响应可接收的Content-Type。HTTP_ACCEPT_ENCODING
—— 响应可接收的编码。HTTP_ACCEPT_LANGUAGE
—— 响应可接收的语言。HTTP_HOST
—— 客服端发送的HTTP Host 头部。HTTP_REFERER
—— Referring 页面。HTTP_USER_AGENT
—— 客户端的user-agent 字符串。QUERY_STRING
—— 单个字符串形式的查询字符串(未解析过的形式)。REMOTE_ADDR
—— 客户端的IP 地址。REMOTE_HOST
—— 客户端的主机名。REMOTE_USER
—— 服务器认证后的用户。REQUEST_METHOD
—— 一个字符串,例如"GET"
或"POST"
。SERVER_NAME
—— 服务器的主机名。SERVER_PORT
—— 服务器的端口(是一个字符串)。从上面可以看到,除CONTENT_LENGTH
和CONTENT_TYPE
之外,请求中的任何HTTP 头部转换为HTTP_
的键时,都会将所有字母大写并将连接符替换为下划线最后加上META
前缀。 所以,一个叫做X-Bender
的头部将转换成META
中的HTTP_X_BENDER
键。
请注意,runserver
将名称中带有下划线的所有标题剥离,因此您将不会在META
中看到它们。 这可以根据WSGI环境变量中下划线的标点和下划线之间的歧义来防止标题欺骗。 它匹配像Nginx和Apache 2.4+之类的Web服务器的行为。
HttpRequest.
resolver_match
¶代表已解析的URL的ResolverMatch
的实例。 此属性仅在URL解析发生后设置,这意味着它可以在所有视图中使用,但不能在URL解析之前执行的中间件(您可以在process_view()
中使用它)。
Django不会自己设置这些属性,而是由应用程序设置使用它们。
HttpRequest.
urlconf
¶这将用作当前请求的根URLconf,覆盖ROOT_URLCONF
设置。 细节参见How Django processes a request。
urlconf
可以设置为None
,以恢复以前的中间件所做的任何更改,并返回使用ROOT_URLCONF
。
Django的contrib应用中包含的一些中间件会在请求上设置属性。 如果没有在请求中看到属性,请确保在MIDDLEWARE
中列出了正确的中间件类。
HttpRequest.
session
¶从SessionMiddleware
:一个可读写的,类似字典的对象,表示当前会话。
HttpRequest.
site
¶从CurrentSiteMiddleware
:代表当前站点的get_current_site()
返回的Site
或RequestSite
的实例。
HttpRequest.
user
¶来自AuthenticationMiddleware
:表示当前登录的用户的AUTH_USER_MODEL
的实例。 如果用户当前未登录,则user
将被设置为AnonymousUser
的实例。 您可以使用is_authenticated
将它们分开,如下所示:
if request.user.is_authenticated:
... # Do something for logged-in users.
else:
... # Do something for anonymous users.
HttpRequest.
get_host
()[source]¶根据从HTTP_X_FORWARDED_HOST
(如果打开USE_X_FORWARDED_HOST
)和HTTP_HOST
头部信息返回请求的原始主机。 如果这两个头部没有提供相应的值,则使用SERVER_NAME
和SERVER_PORT
,在PEP 3333 中有详细描述。
例如:"127.0.0.1:8000"
注
当主机位于多个代理的后面,get_host()
方法将会失败。 有一个解决办法是使用中间件重写代理的头部,例如下面的例子:
from django.utils.deprecation import MiddlewareMixin
class MultipleProxyMiddleware(MiddlewareMixin):
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_port
()[source]¶使用HTTP_X_FORWARDED_PORT
(如果USE_X_FORWARDED_PORT
启用)和SERVER_PORT
META
变量的信息返回请求的始发端口, 以该顺序。
HttpRequest.
build_absolute_uri
(location)[source]¶返回location
的绝对URI。 如果location 没有提供,则设置为request.get_full_path()
。
如果URI 已经是一个绝对的URI,将不会修改。 否则,使用请求中的服务器相关的变量构建绝对URI。
示例:"https://example.com/music/bands/the_beatles/?print=true"
注
不鼓励在同一站点混合HTTP和HTTPS,因此,build_absolute_uri()
将始终生成与当前请求具有相同方案的绝对URI。 如果您需要将用户重定向到HTTPS,最好让Web服务器将所有HTTP流量重定向到HTTPS。
返回签名过的Cookie 对应的值,如果签名不再合法则返回django.core.signing.BadSignature
。 如果提供default
参数,将不会引发异常并返回default 的值。
可选参数salt
可以用来对安全密钥强力攻击提供额外的保护。 max_age
参数用于检查Cookie 对应的时间戳以确保Cookie 的时间不会超过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
更多信息参见cryptographic signing。
HttpRequest.
is_ajax
()[source]¶如果请求是通过True
发起的,则返回XMLHttpRequest
,方法是检查'XMLHttpRequest'
头部是否是字符串HTTP_X_REQUESTED_WITH
。 大部分现代的JavaScript 库都会发送这个头部。
如果您编写自己的XMLHttpRequest
调用(在浏览器端),如果希望is_ajax()
工作,则必须手动设置此标题。
如果响应是否通过AJAX请求而变化,并且您正在使用某种形式的缓存,例如Django的cache middleware
,则应该装饰查看与vary_on_headers('X-Requested-With')
,以便响应正确缓存。
HttpRequest.
__iter__
()¶从HttpRequest
实例读取文件接口的方法。 这使得可以用流的方式读取进来的请求。 常见的用例是使用迭代解析器处理大型XML有效负载,而不会在内存中构建整个XML树。
给定此标准接口,可以将HttpRequest
实例直接传递到XML解析器,例如ElementTree
:
import xml.etree.ElementTree as ET
for element in ET.iterparse(request):
process(element)
QueryDict
对象¶在HttpRequest
对象中,GET
和POST
属性是django.http.QueryDict
的实例,像类定制来处理同一个键的多个值。 这个类的需求来自某些HTML 表单元素传递多个值给同一个键,<select multiple>
是一个显著的例子。
QueryDict
的request.POST
和request.GET
在一个正常的请求/响应循环中是不可变的。 要获取可变版本,您需要使用QueryDict.copy()
。
QueryDict
实现了字典的所有标准方法,因为它是字典的子类。 下面列出了不同点:
QueryDict.
__init__
(query_string=None, mutable=False, encoding=None)[source]¶基于QueryDict
实例化query_string
一个对象。
>>> QueryDict('a=1&a=2&c=3')
<QueryDict: {'a': ['1', '2'], 'c': ['3']}>
If query_string
没被传入, QueryDict
的结果 是空的 (将没有键和值).
您最常遇到的QueryDict
,特别是request.POST
和request.GET
中的那些,将是不可变的。 如果需要实例化你自己的可以修改的对象,通过往它的mutable=True
方法来传递参数 __init__()
可以实现。 .
设置键和值的字符串都将从encoding
转换为unicode。 如果encoding
未设置,则默认为DEFAULT_CHARSET
。
QueryDict.
fromkeys
(iterable, value='', mutable=False, encoding=None)[source]¶使用iterable
中的键创建一个新的QueryDict
,每个值等于value
。 像这样:
>>> QueryDict.fromkeys(['a', 'a', 'b'], value='val')
<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>
QueryDict.
__getitem__
(key)¶返回给出的key 的值。 如果键具有多个值,则返回最后一个值。 如果key 不存在,则引发django.utils.datastructures.MultiValueDictKeyError
。 (这是Python标准KeyError
的子类,所以你可以坚持抓住KeyError
。)
QueryDict.
__setitem__
(key, value)[source]¶将给定的键设置为[value]
(单个元素为value
的列表)。 请注意,作为具有副作用的其他字典函数,只能在可变的QueryDict
(例如通过QueryDict.copy()
)创建的字典函数中调用。
QueryDict.
__contains__
(key)¶如果给出的key 已经设置,则返回True
。 它让你可以做if "foo" in request.GET
这样的操作。
QueryDict.
get
(key, default=None)¶使用与__getitem__()
相同的逻辑,如果该键不存在,则返回默认值。
QueryDict.
setdefault
(key, default=None)[source]¶像dict.setdefault()
,除了它在内部使用__setitem__()
。
QueryDict.
update
(other_dict)¶采用QueryDict
或字典。 像dict.update()
一样但是将条目添加到当前的字典,而并不会替换它们。 像这样:
>>> q = QueryDict('a=1', mutable=True)
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # returns the last
'2'
QueryDict.
items
()¶像dict.items()
,除了它使用与__getitem__()
相同的最后一个值逻辑。 像这样:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '3')]
QueryDict.
iteritems
()¶像dict.iteritems()
,除了它使用与__getitem__()
相同的最后一个值逻辑。
仅适用于Python 2。
QueryDict.
iterlists
()¶类似QueryDict.iteritems()
,只是它将字典中的每个成员作为列表。
仅适用于Python 2。
QueryDict.
values
()¶像dict.values()
,除了它使用与__getitem__()
相同的最后一个值逻辑。 像这样:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.values()
['3']
QueryDict.
itervalues
()¶类似QueryDict.values()
,只是它是一个迭代器。
仅适用于Python 2。
另外,QueryDict
具有以下方法︰
QueryDict.
copy
()[source]¶使用copy.deepcopy()
返回对象的副本。 此副本是可变的即使原始对象是不可变的。
QueryDict.
getlist
(key,default = None)¶返回具有请求密钥的数据列表。 如果该键不存在并且未提供默认值,则返回一个空列表。 保证返回列表,除非提供的默认值不是列表。
QueryDict.
setlist
(key,list _)[source] ¶设置给定的键为list_
(与__setitem__()
不同)。
QueryDict.
setlistdefault
(key,default_list = None)[source] ¶像setdefault()
,除了它需要一个值而不是单个值。
QueryDict.
lists
()¶类似items()
,只是它将字典中的每个成员作为列表。 像这样:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]
QueryDict.
pop
(key)[source]¶返回给定键的值的列表,并从字典中移除它们。 如果键不存在,将引发KeyError
。 像这样:
>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.pop('a')
['1', '2', '3']
QueryDict.
popitem
()[source]¶删除字典任意一个成员(因为没有顺序的概念),并返回二值元组,包含键和键的所有值的列表。 在一个空的字典上调用时将引发KeyError
。 像这样:
>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.popitem()
('a', ['1', '2', '3'])
QueryDict.
dict
()¶返回QueryDict
的dict
表示。 对于QueryDict
中的每个(键,列表)对,dict
将具有(key,item),其中item是列表的一个元素,使用与QueryDict.__getitem__()
>>> q = QueryDict('a=1&a=3&a=5')
>>> q.dict()
{'a': '5'}
HttpResponse
对象¶与由Django自动创建的HttpRequest
对象相比,HttpResponse
对象由程序员创建. 您编写的每个视图都负责实例化,填充和返回一个HttpResponse
。
HttpResponse
类是在django.http
模块中定义的。
典型的应用是传递一个字符串作为页面的内容到HttpResponse
构造函数:
>>> from django.http import 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
将立即处理这个迭代器, 把它的内容存成字符串,然后丢弃它。 具有close()
方法(例如文件和生成器)的对象将立即关闭。
如果你需要从迭代器到客户端的数据数据流的形式响应, 你必须用StreamingHttpResponse
类代替;.
当WSGI服务器在响应时调用close()
时,具有close()
方法的对象将被关闭。
把它当作一个类似字典的结构,从你的response中设置和移除一个header field。
>>> response = HttpResponse()
>>> response['Age'] = 120
>>> del response['Age']
注意!与字典不同的是,如果要删除的header field不存在,del
不会抛出KeyError
异常。
对于设置Cache-Control
和Vary
头字段,建议使用django.utils.cache
中的patch_cache_control()
和patch_vary_headers()
方法,因为这些字段可以有多个逗号分隔的值。 “补丁”方法确保其他值,例如,通过中间件添加的,不会删除。
HTTP header fields 不能包含换行。 当我们尝试让header field包含一个换行符(CR 或者 LF),那么将会抛出一个BadHeaderError
异常。
让浏览器以文件附件的形式处理响应, 需要声明 content_type
类型 和设置 Content-Disposition
头信息. 例如,下面是 如何给浏览器返回一个微软电子表格:
>>> response = HttpResponse(my_data, content_type='application/vnd.ms-excel')
>>> response['Content-Disposition'] = 'attachment; filename="foo.xls"'
没有关于Content-Disposition
头的Django特定的,但是很容易忘记语法,所以我们在这里包括它。
HttpResponse.
content
¶一个用来代替content的字节字符串,如果必要,则从一个Unicode对象编码而来。
HttpResponse.
charset
¶一个字符串,用来表示response将会被编码的字符集。 如果没有在HttpResponse
实例化的时候给定这个字符集,那么将会从content_type
中解析出来。并且当这种解析成功的时候,DEFAULT_CHARSET
选项将会被使用。
HttpResponse.
status_code
¶响应的 HTTP status code。
除非明确设置了reason_phrase
,否则在构造函数之外修改status_code
的值也会修改reason_phrase
的值。
HttpResponse.
reason_phrase
¶响应的HTTP原因短语。 它使用 HTTP standard’s默认原因短语。
除非明确设置,否则reason_phrase
由status_code
的值决定。
HttpResponse.
streaming
¶这个选项总是False
。
由于这个属性的存在,使得中间件(middleware)能够区别对待流式response和常规response。
HttpResponse.
closed
¶True
如果响应已关闭。
HttpResponse.
__init__
(content='', content_type=None, status=200, reason=None, charset=None)[source]¶使用页面的内容(content)和content-type来实例化一个HttpResponse
对象。
content
应该是一个迭代器或者字符串。 如果它是一个迭代器,那么它应该返回一串字符串,并且这些字符串连接起来形成response的内容。 如果不是迭代器或者字符串,那么在其被接收的时候将转换成字符串。
content_type
是可选地通过字符集编码完成的MIME类型,并且用于填充HTTP Content-Type
头部。 如果未指定,它由默认情况下由 DEFAULT_CONTENT_TYPE
和 DEFAULT_CHARSET
设置组成,默认为“text/html; charset=utf-8”。
status
是响应的 HTTP status code。
reason
是HTTP响应短语 如果没有指定, 则使用默认响应短语.
charset
在response中被编码的字符集。 如果没有给定,将会从 content_type
中提取, 如果提取不成功, 那么 DEFAULT_CHARSET
的设定将被使用.
HttpResponse.
__setitem__
(header, value)¶由给定的首部名称和值设定相应的报文首部。 header
和 value
都应该是字符串类型。
HttpResponse.
__delitem__
(header)¶根据给定的首部名称来删除报文中的首部。 如果对应的首部不存在将沉默地(不引发异常)失败。 不区分大小写。
HttpResponse.
__getitem__
(header)¶根据首部名称返回其值。 不区分大小写。
HttpResponse.
has_header
(header)¶通过检查首部中是否有给定的首部名称(不区分大小写),来返回True
或 False
。
HttpResponse.
setdefault
(header, value)¶设置一个首部,除非该首部 header 已经存在了。
设置一个Cookie。 参数与Python 标准库中的Morsel
Cookie 对象相同。
max_age
以秒为单位,如果Cookie 只应该持续客户端浏览器的会话时长则应该为None
(默认值)。
如果没有指定expires
,则会通过计算得到。
expires
应该是一个 UTC "Wdy, DD-Mon-YY HH:MM:SS GMT"
格式的字符串,或者一个datetime.datetime
对象。 如果expires
是一个datetime
对象,则max_age
会通过计算得到。
如果你想设置一个跨域的Cookie,请使用domain
参数。 例如,domain=".lawrence.com"
将设置一个www.lawrence.com、blogs.lawrence.com 和calendars.lawrence.com 都可读的Cookie。 否则,Cookie 将只能被设置它的域读取。
如果你想阻止客服端的JavaScript 访问Cookie,可以设置httponly=True
。
HTTPOnly 是包含在HTTP 响应头部Set-Cookie 中的一个标记。 它不是RFC 2109 中Cookie 的标准,也并没有被所有的浏览器支持。 但是,当它受到尊重时,它可以是减轻客户端脚本访问受保护的cookie数据的风险的有用方式。
与set_cookie()
类似,但是在设置之前将cryptographic signing。 通常与HttpRequest.get_signed_cookie()
一起使用。
你可以使用可选的salt
参考来增加密钥强度,但需要记住将它传递给对应的HttpRequest.get_signed_cookie()
调用。
删除指定的key 的Cookie。 如果key 不存在则什么也不发生。
由于Cookie 的工作方式,path
和domain
应该与set_cookie()
中使用的值相同 —— 否则Cookie 不会删掉。
HttpResponse.
write
(content)[source]¶此方法使HttpResponse
实例是一个类似文件的对象。
HttpResponse.
flush
()¶此方法使HttpResponse
实例是一个类似文件的对象。
HttpResponse.
tell
()[source]¶此方法使HttpResponse
实例是一个类似文件的对象。
HttpResponse.
getvalue
()[source]¶返回HttpResponse.content
的值。 此方法使HttpResponse
实例是一个类似流的对象。
HttpResponse.
readable
()¶始终False
。 此方法使HttpResponse
实例是一个类似流的对象。
HttpResponse.
seekable
()¶始终False
。 此方法使HttpResponse
实例是一个类似流的对象。
HttpResponse.
writable
()[source]¶始终为True
。 此方法使HttpResponse
实例是一个类似流的对象。
HttpResponse.
writelines
(lines)[source]¶将一个包含行的列表写入响应。 不添加行分隔符。 此方法使HttpResponse
实例是一个类似流的对象。
HttpResponse
的子类¶Django包含了一系列的HttpResponse
衍生类(子类),用来处理不同类型的HTTP 响应(response)。 与 HttpResponse
相同, 这些衍生类(子类)存在于django.http
之中。
HttpResponseRedirect
[source]¶构造函数的第一个参数是必要的 — 用来重定向的地址。 该参数可以是一个完整的URL地址(如'https://www.yahoo.com/search/'
),或者是一个相对于项目的绝对路径(如 '/search/'
),还可以是一个相对路径(如 'search/'
)。 在最后一种情况下,客户端浏览器将根据当前路径重建完整的URL本身。 关于构造函数的其他参数,可以参见 HttpResponse
。 注意!这个响应会返回一个302的HTTP状态码。
url
¶这个只读属性表示响应将会重定向的URL地址(相当于Location
response hader)。
HttpResponsePermanentRedirect
[source]¶与HttpResponseRedirect
一样,但是它会返回一个永久的重定向(HTTP状态码301)而不是一个“found”重定向(状态码302)。
HttpResponseNotModified
[source]¶构造函数不会有任何的参数,并且不应该向这个响应(response)中加入内容(content)。 使用此选项可指定自用户上次请求(状态代码304)以来尚未修改页面。
HttpResponseBadRequest
[source]¶与HttpResponse
的行为类似,但是使用了一个400的状态码。
HttpResponseNotFound
[source]¶与HttpResponse
的行为类似,但是使用的404状态码。
HttpResponseForbidden
[source]¶与HttpResponse
类似,但使用403状态代码。
HttpResponseNotAllowed
[source]¶与HttpResponse
类似,但使用405状态码。 构造函数的第一个参数是必须的:一个允许使用的方法构成的列表(例如,['GET', 'POST']
)。
HttpResponseGone
[source]¶与HttpResponse
类似,但使用410状态码。
HttpResponseServerError
[source]¶与HttpResponse
类似,但使用500状态代码。
注
如果HttpResponse
的自定义子类实现了render
方法,Django会将其视为模拟SimpleTemplateResponse
,且render
方法必须自己返回一个有效的响应对象。
JsonResponse
对象¶JsonResponse
(data, encoder=DjangoJSONEncoder, safe=True, json_dumps_params=None, **kwargs)[source]¶HttpResponse
的一个子类,帮助用户创建JSON 编码的响应。 它从父类继承大部分行为,并具有以下不同点:
它的默认Content-Type
头部设置为application/json
。
它的第一个参数data
,应该为一个dict
实例。 如果safe
参数设置为False
,它可以是任何可JSON 序列化的对象。
encoder
,默认为 django.core.serializers.json.DjangoJSONEncoder
,用于序列化data。 关于这个序列化的更多信息参见JSON serialization。
布尔参数safe
默认为True
。 如果设置为False
,可以传递任何对象进行序列化(否则,只允许dict
实例)。 如果safe
为True
,而第一个参数传递的不是dict
对象,将抛出一个TypeError
。
json_dumps_params
参数是传递给用于生成响应的json.dumps()
调用的关键字参数的字典。
典型的用法如下:
>>> from django.http import JsonResponse
>>> response = JsonResponse({'foo': 'bar'})
>>> response.content
b'{"foo": "bar"}'
若要序列化非dict
对象,你必须设置safe
参数为False
:
>>> response = JsonResponse([1, 2, 3], safe=False)
如果不传递safe=False
,将抛出一个TypeError
。
警告
在第五版ECMAScript之前,可能会使JavaScript Array
构造函数崩溃。 出于这个原因,Django 默认不允许传递非字典对象给JsonResponse
构造函数。 然而,现代的大部分浏览器都已经实现EcmaScript 5,它删除了这种攻击性的数组。
所以可以不用关注这个安全预防措施。
如果你需要使用不同的JSON 编码器类,你可以传递encoder
参数给构造函数:
>>> response = JsonResponse(data, encoder=MyJSONEncoder)
StreamingHttpResponse
对象¶StreamingHttpResponse
类被用来从Django流式化一个响应(response)到浏览器。 如果生成响应太长或者是有使用太多的内存,你可能会想要这样做。 例如,它对于generating large CSV files非常有用。
基于性能的考虑
Django是为了那些短期的请求(request)设计的。 流式响应将会为整个响应期协同工作进程。 这可能导致性能变差。
总的来说,你需要将代价高的任务移除请求—响应的循环,而不是求助于流式响应。
StreamingHttpResponse
不是 HttpResponse
的衍生类(子类),因为它实现了完全不同的应用程序接口(API)。 尽管如此,除了以下的几个明显不同的地方,其他几乎完全相同:
content
属性。 取而代之的是,它有一个 streaming_content
属性。tell()
或者 write()
方法。
那么做会抛出一个异常。StreamingHttpResponse
应仅在绝对需要在将数据传输到客户端之前不重复整个内容的情况下使用。 由于无法访问内容,因此许多中间件无法正常运行。 例如,不能为流响应生成ETag
和Content-Length
头。
StreamingHttpResponse.
streaming_content
¶一个表示内容(content)的字符串的迭代器
StreamingHttpResponse.
status_code
¶响应的 HTTP status code。
除非明确设置了reason_phrase
,否则在构造函数之外修改status_code
的值也会修改reason_phrase
的值。
StreamingHttpResponse.
reason_phrase
¶响应的HTTP原因短语。 它使用 HTTP standard’s默认原因短语。
除非明确设置,否则reason_phrase
由status_code
的值决定。
StreamingHttpResponse.
streaming
¶这个选项总是 True
.
FileResponse
对象¶FileResponse
是StreamingHttpResponse
的衍生类(子类),为二进制文件做了优化。 如果 wsgi server 来提供,则使用了 wsgi.file_wrapper ,否则将会流式化一个文件为一些小块。
FileResponse
需要通过二进制模式打开文件,如下:
>>> from django.http import FileResponse
>>> response = FileResponse(open('myfile.png', 'rb'))
2017年9月6日