HTTP 應用的信息是通過 請求報文 和 響應報文 傳遞的
其中 請求報文 由客戶端發送，而 django 將這些信息封裝成了 HttpRequest 對象，該對象由 HttpRequest 類創建。
每一個請求都會生成一個 HttpRequest 對象，django會將這個對象自動傳遞給響應的視圖函數，一般視圖函數約定俗成地使用 request 參數承接這個對象。
def index(requset):
#request.POST
#request.GET
return render(requset, 'index.html')
Request屬性：
django將請求報文中的請求行、首部信息、內容主體封裝成 HttpRequest 類中的屬性。(除了特殊說明的之外，其他均爲只讀)
1.HttpRequest.scheme
一個字符串，代表請求的方案，一般爲 ‘http’ 或 ‘https’。
2.HttpRequest.body
一個字符串，代表請求報文的主體。在處理非 HTTP 形式的報文時非常有用，例如：二進制圖片、XML等。
但是，如果要處理表單數據的時候，推薦還是使用 HttpRequest.POST 。
另外，我們還可以用 python 的類文件方法去操作它，詳情參考 HttpRequest.read() 。
3.HttpRequest.path
一個字符串，表示請求的路徑組件（不含域名）。
例如："/music/bands/the_beatles/"
4.HttpRequest.path_info
一個字符串，在某些 Web 服務器配置下，主機名後的 URL 部分被分成腳本前綴部分和路徑信息部分。path_info 屬性將始終包含路徑信息部分，不論使用的Web 服務器是什麼。使用它代替 path 可以讓代碼在測試和開發環境中更容易地切換。
例如，如果應用的WSGIScriptAlias 設置爲"/minfo"，那麼當 path 是"/minfo/music/bands/the_beatles/" 時path_info 將是"/music/bands/the_beatles/"。
5.HttpRequest.method
一個字符串，表示請求使用的HTTP 方法。必須使用大寫。
例如："GET"、"POST"
6.HttpRequest.encoding
一個字符串，表示提交的數據的編碼方式（如果爲 None 則表示使用 DEFAULT_CHARSET 的設置，默認爲 'utf-8'）。這個屬性是可寫的，你可以修改它來修改訪問表單數據使用的編碼。接下來對屬性的任何訪問（例如從 GET 或 POST 中讀取數據）將使用新的 encoding 值。如果你知道表單數據的編碼不是 DEFAULT_CHARSET ，則使用它。
7.HttpRequest.GET
一個類似於字典的對象，包含 HTTP GET 的所有參數。詳情請參考 QueryDict 對象。
8.HttpRequest.POST
一個類似於字典的對象，如果請求中包含表單數據，則將這些數據封裝成 QueryDict 對象。
POST 請求可以帶有空的 POST 字典 —— 如果通過 HTTP POST 方法發送一個表單，但是表單中沒有任何的數據，QueryDict 對象依然會被創建。因此，不應該使用 if request.POST 來檢查使用的是否是POST 方法；應該使用 ifrequest.method == "POST"
另外：如果使用 POST 上傳文件的話，文件信息將包含在 FILES 屬性中。
9.HttpRequest.REQUEST
一個類似於字典的對象，它首先搜索POST，然後搜索GET，主要是爲了方便。靈感來自於PHP 的 $_REQUEST。
例如，如果 GET = {"name": "john"} 而 POST = {"age": '34'} ， REQUEST["name"] 將等於"john"， REQUEST["age"] 將等於"34"。
強烈建議使用 GET 和 POST 而不要用REQUEST，因爲它們更加明確。
10.HttpRequest.COOKIES
一個標準的Python 字典，包含所有的cookie。鍵和值都爲字符串。
11.HttpRequest.FILES
一個類似於字典的對象，包含所有的上傳文件信息。FILES 中的每個鍵爲<input type="file" name="" /> 中的name，值則爲對應的數據。
注意，FILES 只有在請求的方法爲POST 且提交的<form> 帶有enctype="multipart/form-data" 的情況下才會包含數據。否則，FILES 將爲一個空的類似於字典的對象。
12.HttpRequest.META
一個標準的Python 字典，包含所有的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 首部轉換爲 META 的鍵時，都會將所有字母大寫並將連接符替換爲下劃線最後加上 HTTP_ 前綴。所以，一個叫做 X-Bender 的頭部將轉換成 META 中的 HTTP_X_BENDER 鍵。
13.HttpRequest.user
一個 AUTH_USER_MODEL 類型的對象，表示當前登錄的用戶。
如果用戶當前沒有登錄，user 將設置爲 django.contrib.auth.models.AnonymousUser 的一個實例。可以通過 is_authenticated() 區分它們。
if request.user.is_authenticated():
14.HttpRequest.session
一個既可讀又可寫的類似於字典的對象，表示當前的會話。只有當Django 啓用會話的支持時纔可用。
15.HttpRequest.urlconf
不是由Django 自身定義的，但是如果其它代碼（例如，自定義的中間件類）設置了它，Django 就會讀取它。如果存在，它將用來作爲當前的請求的Root URLconf，並覆蓋ROOT_URLCONF設置。
16.HttpRequest.resolver_match
一個ResolverMatch的實例，表示解析後的URL。這個屬性只有在 URL 解析方法之後才設置，這意味着它在所有的視圖中可以訪問，但是在 URL 解析發生之前執行的中間件方法中不可以訪問（比如process_request，但你可以使用 process_view 代替）。