附录 H HTTP 请求（Request）和回应（Response）对象

Django 使用 request 和 response 对象在系统间传递状态。—(阿伦)

当一个页面被请示时，Django 创建一个包含请求元数据的 HttpRequest 对象。 然后 Django调入合适的视图，把 HttpRequest 作为视图的函数的第一个参数 传入。每个视图要负责返回一个 HttpResponse 对象。

我们在书中已经使用过这些对象了；这篇附录说明了 HttpRequest 和 HttpResponse 的全部

API。

HttpRequest 对象

HttpRequest 表示来自某客户端的一个单独的 HTTP 请求。

HttpRequest 实例的属性包含了关于此次请求的大多数重要信息(详见表 H-1)。除了 session外的所有属性都应该认为是只读的.

。

• filename ：字符串，表示上传文件的文件名。

• content-type ：上传文件的内容类型。

• content ：上传文件的原始内容。

• CONTENT_LENGTH

• CONTENT_TYPE

• QUERY_STRING ：未解析的原始请求字符串。

• REMOTE_ADDR ：客户端 IP 地址。

• REMOTE_HOST ：客户端主机名。

• SERVER_NAME ：服务器主机名。

• SERVER_PORT ：服务器端口号。

• HTTP_ACCEPT_ENCODING

• HTTP_ACCEPT_LANGUAGE

• HTTP_HOST ：客户端发送的 Host 头信息。

• HTTP_REFERER ：被指向的页面，如果存在的。

• HTTP_USER_AGENT ：客户端的 user-agent 字符串。

• HTTP_X_BENDER ： X-Bender 头信息的值， 如果已设的话。

Request 对象同样包含了一些有用的方法，见表 H-2。

QueryDict 对象

在一个 HttpRequest 对象中， GET 和 POST 属性都是 django.http.QueryDict 的实例。

QueryDict 是一个类似于字典的类，专门用来处理用一个键的多值。当处理一些 HTML 表单中的元素，特别是 <select multiple="multiple"> 之类传递同一 key 的多值的元素时，就需要这个类了。

QueryDict 实例是不可变的，除非创建了一个 copy() 副本。也就是说不能直接更改

request.POST 和 request.GET 的属性。

QueryDict 实现了所有标准的字典的方法，因为它正是字典的一个子类。与其不同的东西都已在表 H-3 中列出。

另外， QueryDict 还有在表 H-4 中列出的方法。

一个完整的例子

例如, 给定这个 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 中。 System Message: ERROR/3 (<string>, line 537)

  Error parsing content block for the “table” directive: exactly one table expected.

  .. table:: 表 H-5. HttpResponse 子类

  +---------------------------------+-------------------------------------------+

  | 类 名 | 描 述

  |

  +=================================+===========================================+

  |``HttpResponseRedirect`` |构造函数的参数有一个：

  |

  | | 重 定 向 的 路 径 。 它 可 以 是 一 个 完 整 的 URL

  |

  | |（ 例 如 ， ``'http://search.yahoo.com/'`` ）

  |

  | | 或 者 不 包 括 域 名 的 绝 对 路 径 （ 如

  |

  | |``'/search/'`` ） 。 注 意 它 返 回

  |

  | |HTTP 状 态 码 302 。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponsePermanentRedirect``|类似 ``HttpResponseRedirect`` ， 但是它

  |

  | | 返 回 一 个 永 久 重 定 向 （HTTP 状 态 码 301），

  |

  | | 而 不 是 暂 时 性 重 定 向 （ 状 态 码 302） 。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseNotModified`` |构造函数没有任何参数。

  |

  | | 用 它 来 表 示 这 个 页 面 在 上 次 请 求 后 未 改 变 。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseBadRequest`` |类似 ``HttpResponse`` ，但使用 400 状态码。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseNotFound`` |类似 ``HttpResponse`` ，但使用 404 状态码。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseForbidden`` |类似 ``HttpResponse`` ，但使用 403 状态码。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseNotAllowed`` |类似 ``HttpResponse`` ，但使用 405 状态码。

  |

  | | 它 必 须 有 一 个 参 数 ：

  |

  | | 允 许 方 法 的 列 表 。

  |

  | |（ 例 如 ， ``['GET', 'POST']`` ） 。 |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseGone`` |类似 ``HttpResponse`` ，但使用 410 状态码。

  |

  +---------------------------------+-------------------------------------------+

  |``HttpResponseServerError`` |类似 ``HttpResponse`` ，但使用 500 状态码。

  |

  +---------------------------------+-------------------------------------------+

  当然，如果框架不支持一些特性，你也可以定义自己的 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'