HTTP請求（Request）和迴應（Response）對象

時間  2019-11-09
標籤 http 請求 request 迴應 response 對象 欄目 HTTP/TCP 简体版
原文   原文鏈接

附錄H HTTP請求（Request）和迴應（Response）對象

57
http://djangobook.py3k.cn/

Django使用request和response對象在系統間傳遞狀態。html

 

當一個頁面被請示時，Django建立一個包含請求元數據的 HttpRequest 對象。 而後Django調入合適的視圖，把 HttpRequest 做爲視圖函數的第一個參數 傳入。每一個視圖要負責返回一個 HttpResponse 對象。正則表達式

 

咱們在書中已經使用過這些對象了；這篇附錄說明了 HttpRequest 和 HttpResponse 的所有API。django

 

HttpRequest對象

 

HttpRequest 表示來自某客戶端的一個單獨的HTTP請求。安全

1

HttpRequest實例的屬性包含了關於這次請求的大多數重要信息(詳見表H-1)。 除了session外的全部屬性都應該認爲是隻讀的.服務器

 
  
表 H-1. HttpRequest對象的屬性
屬性 描述
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字典， 包含如下三個鍵：

  • 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>
1

若是用戶在 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 對象。

1

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})
1

爲了徹底發揮出 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 *
1

這句話負責當前模塊中的 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'
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程