當一個頁面被請示時，Django創建一個包含請求元數據的 HttpRequest 對象。然後Django調入合適的視圖，把 HttpRequest 作爲視圖的函數的第一個參數傳入。每個視圖要負責返回一個 HttpResponse 對象。
我們在書中已經使用過這些對象了；這篇附錄說明了 HttpRequest 和 HttpResponse 的全部API。
HttpRequest對象
HttpRequest 表示來自某客戶端的一個單獨的HTTP請求。
HttpRequest實例的屬性包含了關於此次請求的大多數重要信息(詳見表H-1)。 除了session外的所有屬性都應該認爲是隻讀的.
|
表 H-1. HttpRequest對象的屬性 |
|
|
屬性 |
描述 |
|
path |
表示提交請求頁面完整地址的字符串，不包括域名，如 "/music/bands/the_beatles/"。 |
|
method |
表示提交請求使用的HTTP方法。它總是大寫的。例如： if request.method == 'GET': do_something() elif request.method == 'POST': do_something_else() |
|
GET |
一個類字典對象，包含所有的HTTP的GET參數的信息。見 QueryDict 文檔。 |
|
POST |
一個類字典對象，包含所有的HTTP的POST參數的信息。見 QueryDict 文檔。 通過POST提交的請求有可能包含一個空的 POST 字典，也就是說， 一個通過POST方法提交的表單可能不包含數據。因此，不應該使用 if request.POST 來判斷POST方法的使用，而是使用 if request.method == "POST" （見表中的 method 條目）。 注意： 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字典，包含以下三個鍵： filename ：字符串，表示上傳文件的文件名。 content-type ：上傳文件的內容類型。 content ：上傳文件的原始內容。 注意 FILES 只在請求的方法是 POST ，並且提交的 <form> 包含enctype="multipart/form-data" 時才包含數據。否則， FILES 只是一個空的類字典對象。 |
|
META |
一個標準的Python字典，包含所有有效的HTTP頭信息。有效的頭信息與客戶端和服務器有關。這裏有幾個例子： CONTENT_LENGTH CONTENT_TYPE QUERY_STRING ：未解析的原始請求字符串。 REMOTE_ADDR ：客戶端IP地址。 REMOTE_HOST ：客戶端主機名。 SERVER_NAME ：服務器主機名。 SERVER_PORT ：服務器端口號。 在 META 中有效的任一HTTP頭信息都是帶有 HTTP_ 前綴的鍵，例如： HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_HOST ：客戶端發送的 Host 頭信息。 HTTP_REFERER ：被指向的頁面，如果存在的。 HTTP_USER_AGENT ：客戶端的user-agent字符串。 HTTP_X_BENDER ： X-Bender 頭信息的值，如果已設的話。 |
|
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。
|
表 H-2. HttpRequest 的方法 |
|
|
方法 |
描述 |
|
__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中列出。
|
表 H-3. QueryDicts 與標準字典的區別 |
|
|
方法 |
與標準字典實現的不同 |
|
__getitem__ |
與一個字典一樣。但是，當一個鍵有多個值時， __getitem__() 返回最後一個值。 |
|
__setitem__ |
將所給鍵的值設爲 [value] （一個只有一個 value 元素的 Python列表）。 注意，因對其它的字典函數有副作用，故它只能被稱爲一個可變的 QueryDict （通過 copy() 創建）。 |
|
get() |
如果一個鍵多個值，和 __getitem__ 一樣， get() 返回最後一個值。 |
|
update() |
參數是一個 QueryDict 或標準字典。 和標準字典的 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中列出的方法。
|
表 H-4. 附加的 (非字典的) QueryDict 方法 |
|
|
方法 |
描述 |
|
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 中。
|
表 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 ，就像這樣：
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'
