HTTP请求（Request）和回应（Response）对象
附录H HTTP请求（Request）和回应（Response）对象
Django使用request和response对象在系统间传递状态。html
当一个页面被请示时，Django建立一个包含请求元数据的 HttpRequest 对象。 而后Django调入合适的视图，把 HttpRequest 做为视图函数的第一个参数 传入。每一个视图要负责返回一个 HttpResponse 对象。正则表达式
咱们在书中已经使用过这些对象了；这篇附录说明了 HttpRequest 和 HttpResponse 的所有API。django
HttpRequest对象
HttpRequest 表示来自某客户端的一个单独的HTTP请求。安全
HttpRequest实例的属性包含了关于这次请求的大多数重要信息(详见表H-1)。 除了session外的全部属性都应该认为是只读的.服务器
| 属性 | 描述 |
|---|---|
| path | 表示提交请求页面完整地址的字符串， 不包括域名，如 "/music/bands/the_beatles/" 。 |
| method | 表示提交请求使用的HTTP方法。 它老是大写的。例如：cookie if request.method == 'GET':
do_something()
elif request.method == 'POST':
do_something_else()
|
| GET | 一个类字典对象，包含全部的HTTP的GET参数的信息。 见 QueryDict 文档。 |
| POST | 一个类字典对象，包含全部的HTTP的POST参数的信息。 见 QueryDict 文档。session 经过POST提交的请求有可能包含一个空的 POST 字典， 也就是说， 一个经过POST方法提交的表单可能不包含数据。 所以，不该该使用 if request.POST 来判断POST方法的使用， 而是使用 if request.method == "POST" （见表中的 method 条目）。app 注意： POST 并 不 包含文件上传信息。 见 FILES 。框架 |
| REQUEST | 为了方便而建立，这是一个类字典对象，先搜索 POST ， 再搜索 GET 。 灵感来自于PHP的 $_REQEUST 。函数 例如， 若 GET = {"name": "john"} ， POST = {"age": '34'} ， REQUEST["name"] 会是 "john" ， REQUEST["age"] 会是 "34" 。 强烈建议使用 GET 和 POST ，而不是 REQUEST 。 这是为了向前兼容和更清楚的表示。 |
| COOKIES | 一个标准的Python字典，包含全部cookie。 键和值都是字符串。cookie使用的更多信息见第12章。 |
| FILES | 一个类字典对象，包含全部上传的文件。 FILES 的键来自 <input type="file" name="" /> 中的 name 。 FILES 的值是一个标准的Python字典， 包含如下三个键：
注意 FILES 只在请求的方法是 POST ，而且提交的 <form> 包含 enctype="multipart/form-data" 时 才包含数据。不然， FILES 只是一个空的类字典对象。 |
| META | 一个标准的Python字典，包含全部有效的HTTP头信息。 有效的头信息与客户端和服务器有关。 这里有几个例子：
在 META 中有效的任一HTTP头信息都是带有 HTTP_ 前缀的 键，例如：
|
| user | 一个 django.contrib.auth.models.User 对象表示 当前登陆用户。 若当前用户还没有登陆， user 会设为 django.contrib.auth.models.AnonymousUser 的一个实例。 能够将它们与 is_authenticated() 区别开： if request.user.is_authenticated():
# Do something for logged-in users.
else:
# Do something for anonymous users.
user 仅当Django激活 AuthenticationMiddleware 时有效。 关于认证和用户的完整细节，见第12章。 |
| session | 一个可读写的类字典对象，表示当前session。 仅当Django已激活session支持时有效。 见第12章。 |
| raw_post_data | POST的原始数据。 用于对数据的复杂处理。 |
Request对象一样包含了一些有用的方法，见表H-2。
| 方法 | 描述 |
|---|---|
| __getitem__(key) | 请求所给键的GET/POST值，先查找POST，而后是GET。 若键不存在，则引起异常 KeyError 。 该方法使用户能够以访问字典的方式来访问一个 HttpRequest 实例。 例如， request["foo"] 和先检查 request.POST["foo"] 再检查 request.GET["foo"] 一 样。 |
| has_key() | 返回 True 或 False ， 标识 request.GET 或 request.POST 是否包含所给的 键。 |
| get_full_path() | 返回 path ，若请求字符串有效，则附加于其后。 例如， "/music/bands/the_beatles/?print=true" 。 |
| is_secure() | 若是请求是安全的，则返回 True 。 也就是说，请求是以HTTPS的形式提交的。 |
QueryDict 对象
在一个 HttpRequest 对象中， GET 和 POST 属性都是 django.http.QueryDict 的实例。 QueryDict 是一个相似于字典的类，专门用来处理用一个键的多值。当处理一些HTML表单中的元素，特别是 <select multiple="multiple"> 之类传递同一key的多值的元素时，就须要这个类了。
QueryDict 实例是不可变的，除非建立了一个 copy() 副本。也就是说不能直接更改 request.POST 和 request.GET 的属性。
QueryDict 实现了全部标准的字典的方法，由于它正是字典的一个子类。与其不一样的东西都已在表H-3中列出。
| 方法 | 与标准字典实现的不一样 |
|---|---|
| __getitem__ | 与一个字典同样。可是，当一个键有多个值时， __getitem__() 返回最后一个值。 |
| __setitem__ | 将所给键的值设为 [value] （一个只有一个 value 元素的 Python列表）。 注意，因对其它的字典函数有反作用，故它只能被称 为一个可变的 QueryDict （经过 copy() 建立）。 |
| get() | 若是一个键多个值，和 __getitem__ 同样， get() 返回 最后一个值。 |
| update() |
>>> q = QueryDict('a=1')
>>> q = q.copy() # 使其可变
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # 返回最后一个值
['2']
|
| items() | 和标准字典的 items() 方法同样， 不一样的是它和 __getitem()__ 同样，返回最后一个值： >>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '3')]
|
| values() | 和标准字典的 values() 方法同样， 不一样的是它和 __getitem()__ 同样，返回最后一个值。 |
另外， QueryDict 还有在表H-4中列出的方法。
| 方法 | 描述 |
|---|---|
| copy() | 返回一个对象的副本，使用的是Python标准库中的 copy.deepcopy() 。 该副本是可变的， 也就是说，你能改变它的值。 |
| getlist(key) | 以Python列表的形式返回所请求键的数据。 若键不存在则返回空列表。 它保证了必定会返回某种形式的list。 |
| setlist(key, list_) | 将所给键的键值设为 list_ （与 __setitem__() 不一样）。 |
| appendlist(key, item) | 在 key 相关的list上增长 item 。 |
| setlistdefault(key, l) | 和 setdefault 同样， 不一样的是它的第二个参数是 一个列表，而不是一个值。 |
| lists() | 和 items() 同样， 不一样的是它以一个列表的形式 返回字典每个成员的全部值。 例如： >>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]
|
| urlencode() | 返回一个请求字符串格式的数据字符串 （如， "a=2&b=3&b=5" ）。 |
一个完整的例子
例如, 给定这个HTML表单:
<form action="/foo/bar/" method="post">
<input type="text" name="your_name" />
<select multiple="multiple" name="bands">
<option value="beatles">The Beatles</option>
<option value="who">The Who</option>
<option value="zombies">The Zombies</option>
</select>
<input type="submit" />
</form>
若是用户在 your_name 中输入 "John Smith" ，而且在多选框中同时选择了The Beatles和The Zombies，那么如下就是Django的request对象所拥有的：
>>> request.GET
{}
>>> request.POST
{'your_name': ['John Smith'], 'bands': ['beatles', 'zombies']}
>>> request.POST['your_name']
'John Smith'
>>> request.POST['bands']
'zombies'
>>> request.POST.getlist('bands')
['beatles', 'zombies']
>>> request.POST.get('your_name', 'Adrian')
'John Smith'
>>> request.POST.get('nonexistent_field', 'Nowhere Man')
'Nowhere Man'
使用时请注意:
GET , POST , COOKIES , FILES , META , REQUEST , raw_post_data 和 user 这些属性都是延迟加载的。 也就是说除非代码中访问它们，不然Django并不会花费资源来计算这些属性值。
HttpResponse
与Django自动建立的 HttpRequest 对象相比， HttpResponse 对象则是由你建立的。 你建立的每一个视图都须要实例化，处理和返回一个 HttpResponse 对象。
HttpResponse 类存在于 django.http.HttpResponse 。
构造HttpResponse
通常状况下，你建立一个 HttpResponse 时，以字符串的形式来传递页面的内容给 HttpResponse 的构造函数：
>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.", mimetype="text/plain")
可是若是但愿逐渐增长内容，则能够把 response 看成一个类文件对象使用：
>>> response = HttpResponse()
>>> response.write("<p>Here's the text of the Web page.</p>")
>>> response.write("<p>Here's another paragraph.</p>")
你能够将一个迭代器传递给 HttpResponse ，而不是固定的字符串。若是你要这样作的话，请遵循如下规则：
-
迭代器应返回字符串。
-
若一个 HttpResponse 已经经过实例化，并以一个迭代器做为其内容，就不能以一个类文件对象使用 HttpResponse 实例。这样作的话，会致使一个 Exception 。
最后，注意 HttpResponse 实现了一个 write() 方法，使其能够在任何可使用类文件对象的地方使用。 这方面的例子见第11章。
设置 Headers
您可使用字典同样地添加和删除头信息。
>>> response = HttpResponse() >>> response['X-DJANGO'] = "It's the best." >>> del response['X-PHP'] >>> response['X-DJANGO'] "It's the best."
你也可使用 has_header(header) 来检查一个头信息项是否存在。
请避免手工设置 Cookie 头，参见第12章Django中cookie工做原理的说明。
HttpResponse的子类
Django包含许多处理不一样类型的HTTP请求的 HttpResponse 子类（见表H-5）。像 HttpResponse 同样，这些类在 django.http 中。
固然，若是框架不支持一些特性，你也能够定义本身的 HttpResponse 子类来处理不一样的请求。
返回错误
在Django中返回HTTP错误代码很容易。咱们前面已经提到 HttpResponseNotFound ， HttpResponseForbidden ， HttpResponseServerError ，和其它子类。为了更好地表示一个错误，只要返回这些子类之一的一个实例，而不是一个一般的 HttpResponse ，例如：
def my_view(request):
# ...
if foo:
return HttpResponseNotFound('<h1>Page not found</h1>')
else:
return HttpResponse('<h1>Page was found</h1>')
至今为止，404错误是最多见的HTTP错误，有一种更容易的方式来处理。
当返回一个错误，好比 HttpResponseNotFound 时，须要定义错误页面的HTML：
return HttpResponseNotFound('<h1>Page not found</h1>')
为了方便，并且定义一个通用的应用于网站的404错误页面也是一个很好的选择，Django提供了一个 Http404 异常。若是在视图的任何地方引起 Http404 异常，Django就会捕获错误并返回应用程序的标准错误页面，固然，还有HTTP错误代码404。
例如：
from django.http import Http404
def detail(request, poll_id):
try:
p = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise Http404
return render_to_response('polls/detail.html', {'poll': p})
为了彻底发挥出 Http404 的功能，应建立一个模板，在404错误被引起时显示。模板的名字应该是 404.html ，并且应该位于模板树的最高层。
自定义 404 (没法找到) 视图
当引起 Http404 异常，Django加载一个专门处理404错误的视图。默认状况下，这个视图是 django.views.defaults.page_not_found ，它会加载并显示模板 404.html 。
这意味着须要在根模板目录定义一个 404.html 模板。这个模板会做用于全部404错误。
视图 page_not_found 适用于99%的网站应用程序，但如果但愿重载该视图，能够在URLconf中指定 handler404 ，就像这样：sfas
from django.conf.urls.defaults import *
urlpatterns = patterns('',
...
)
handler404 = 'mysite.views.my_custom_404_view'
后台执行时，Django以 handler404 来肯定404视图。默认状况下，URLconf包含如下内容：
from django.conf.urls.defaults import *
这句话负责当前模块中的 handler404 设置。正如你所见，在 django/conf/urls/defaults.py 中， handler404 默认被设为 'django.views.defaults.page_not_found' 。
关于404视图，有三点须要注意：
-
当Django在URLconf没法找到匹配的正则表达式时，404视图会显示。
-
若是没有定义本身的404视图，而只是简单地使用默认的视图，此时就须要在模板目录的根目录建立一个 404.html 模板。默认的404视图会对全部404错误使用改模板。
-
若 DEBUG 被设为 True （在settings模块内），则404视图不会被使用，此时显示的是跟踪信息。
自定义 500 (服务器错误) 视图
一样地，如果在试图代码中出现了运行时错误，Django会进行特殊状况处理。若是视图引起了一个异常，Django会默认访问视图 django.views.defaults.server_error ，加载并显示模板 500.html 。
这意味着须要在根模板目录定义一个 500.html 模板。该模板做用于全部服务器错误。
视图 server_error 适用于99%的网站应用程序，但如果但愿重载该视图，能够在URLconf中指定 handler500 ，就像这样：
from django.conf.urls.defaults import *
urlpatterns = patterns('',
...
)
handler500 = 'mysite.views.my_custom_error_view'
- 1. http请求的request和response
- 2. ASP.NET常用对象——Request(请求)和Response(响应)对象
- 3. Request对象和Response对象
- 4. request对象和response对象
- 5. Scrapy - Request 和 Response（请求和响应）
- 6. request和response对象
- 7. 请求对象 request 和响应对象 response（1）_请求和相应的路径问题
- 8. 14 http协议（请求）&request域对象
- 9. request、response对象
- 10. HTTP协议请求（request）和响应（response）报文分析
- 更多相关文章...
- • HTTP 请求方法 - HTTP 教程
- • ASP Request 对象 - ASP 教程
- • TiDB 在摩拜单车在线数据业务的应用和实践
- • 算法总结-回溯法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. http请求的request和response
- 2. ASP.NET常用对象——Request(请求)和Response(响应)对象
- 3. Request对象和Response对象
- 4. request对象和response对象
- 5. Scrapy - Request 和 Response（请求和响应）
- 6. request和response对象
- 7. 请求对象 request 和响应对象 response（1）_请求和相应的路径问题
- 8. 14 http协议（请求）&request域对象
- 9. request、response对象
- 10. HTTP协议请求（request）和响应（response）报文分析