django從請求到響應的過程
1月30號進行修改，本文本來寫着轉載，到後來發現本文存在一些邏輯錯誤，又再參考了另外幾篇文章，從新更新了一下文章，文末會附幾篇參考文章的地址，有興趣的讀者能夠點進去看。python
django啓動
咱們在啓動一個django項目的時候，不管你是在命令行執行仍是在pycharm直接點擊運行，其實都是執行'runserver'的操做，而ruserver是使用django自帶的的web server，主要用於開發和調試中，而在正式的環境中，通常會使用nginx+uwsgi模式。nginx
不管是哪一種方式，當啓動一個項目，都會作2件事：web
- 建立一個WSGIServer類的實例，接受用戶的請求。
- 當一個用戶的http請求到達的時，爲用戶指定一個WSGIHandler，用於處理用戶請求與響應，這個Handler是處理整個request的核心。
WSGI
WSGI：全稱是Web Server Gateway Interface，WSGI不是服務器，也不用於與程序交互的API，更不是代碼，而只是定義了一個接口，用於描述web server如何與web application通訊的規範。 當客戶端發送一次請求後，最早處理請求的其實是 web 服務器就是咱們常常說的 nginx、Apache 這類的 web 服務器，而後web服務器再把請求交給web應用程序(如django)處理，這中間的中介就是WSGI，它把 web 服務器和 web 框架 (Django) 鏈接起來。 django
# 這段代碼來自python核心編程
def simplr_wsgi_app(environ, start_response):
# 固定兩個參數，django中也使用一樣的變量名
status = '200 OK'
headers = [{'Content-type': 'text/plain'}]
# 初始化響應, 必須在返回前調用
start_response(status, headers)
# 返回可迭代對象
return ['hello world!']
複製代碼
django中，實現一樣邏輯的是經過WSGIHandler這個類，下面咱們也會重點介紹它！ 若是對WSGI與uWSGI有興趣的，推薦你們看這篇文章，WSGI & uwsgi ，大讚！編程
中間件基本概念
顧名思義，中間件是位於Web服務器端和Web應用之間的，它能夠添加額外的功能。當咱們建立一個django項目(經過pycharm)，它會自動幫咱們設置一些必要的中間件。瀏覽器
MIDDLEWARE_CLASSES = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
複製代碼
中間件要麼對來自用戶的數據進行預處理，而後發送給應用；要麼在應用將響應負載返回給用戶以前，對結果數據進行一些最終的調整。通俗一點，在django中，中間可以幫咱們準備好request這個對象，而後應用能夠直接使用request對象獲取到各種數據，也幫咱們將response添加頭部，狀態碼等。bash
數據流
當django接受到一個請求時，會初始化一個WSGIHandler，能夠在項目下的wsgi.py文件進行跟蹤，你就會發現這一個類。服務器
class WSGIHandler(base.BaseHandler):
def __call__(self, environ, start_response):
pass
複製代碼
這個類遵循WSGI應用的規定，它接受2個參數：一個是含有服務器端的環境變量，另外一個是可調用對象，返回一個可迭代對象。 這個handler控制了從請求到響應的整個過程，主要流程：cookie
在網上看到另一張圖，更爲完整：session
大體幾個步驟：
1. 用戶經過瀏覽器請求一個頁面
2. 請求到達Request Middlewares，中間件對request作一些預處理或者直接response請求
3. URLConf經過urls.py文件和請求的URL找到相應的View
4. View Middlewares被訪問，它一樣能夠對request作一些處理或者直接返回response
5. 調用View中的函數
6. View中的方法能夠選擇性的經過Models訪問底層的數據
7. 全部的Model-to-DB的交互都是經過manager完成的
8. 若是須要，Views可使用一個特殊的Context
9. Context被傳給Template用來生成頁面
a.Template使用Filters和Tags去渲染輸出
b.輸出被返回到View
c.HTTPResponse被髮送到Response Middlewares
d.任何Response Middlewares均可以豐富response或者返回一個徹底不一樣的response
e.Response返回到瀏覽器，呈現給用戶
複製代碼
中間類中的順序與方法
django 的中間件類至少含有如下四個方法中的一個：
process_request、 process_view、process_exception、process_response
WSGIHandler經過load_middleware將這個些方法分別添加到_request_middleware、_view_middleware、_response_middleware 和 _exception_middleware四個列表中。
並非每一箇中間件都有這4個方法，若是不存在某個方法，那麼在加載的過程當中，這個類就被跳過。
for middleware_path in settings.MIDDLEWARE_CLASSES:
···
if hasattr(mw_instance, 'process_request'):
request_middleware.append(mw_instance.process_request)
if hasattr(mw_instance, 'process_view'):
self._view_middleware.append(mw_instance.process_view)
if hasattr(mw_instance, 'process_template_response'):
self._template_response_middleware.insert(0, mw_instance.process_template_response)
if hasattr(mw_instance, 'process_response'):
self._response_middleware.insert(0, mw_instance.process_response)
if hasattr(mw_instance, 'process_exception'):
self._exception_middleware.insert(0, mw_instance.process_exception)
複製代碼
咱們能夠從源碼看出，process request 和 process response的執行加載順序正好是相反，在循環中，process_request是被append到列表的末尾，而process_request是被insert到最前面的。
process_request
舉幾個中間件的例子
class CommonMiddleware(object):
# 僞代碼
def process_request(self, request):
# Check for denied User-Agents
if 'HTTP_USER_AGENT' in request.META:
for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
if user_agent_regex.search(request.META['HTTP_USER_AGENT']):
raise PermissionDenied('Forbidden user agent')
host = request.get_host()
if settings.PREPEND_WWW and host and not host.startswith('www.'):
host = 'www.' + host
pass
複製代碼
CommonMiddleware的process_request主要是判斷用戶代理是否符合要求以及在完善URL，如增長www或者末尾加/。
class SessionMiddleware(object):
def process_request(self, request):
session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
request.session = self.SessionStore(session_key)
複製代碼
SessionMiddleware的process_request是把session_key從cookies中取出來而後放到request.session中。
class AuthenticationMiddleware(MiddlewareMixin):
def process_request(self, request):
assert hasattr(request, 'session'), (
"The Django authentication middleware requires session middleware "
"to be installed. Edit your MIDDLEWARE%s setting to insert "
"'django.contrib.sessions.middleware.SessionMiddleware' before "
"'django.contrib.auth.middleware.AuthenticationMiddleware'."
) % ("_CLASSES" if settings.MIDDLEWARE is None else "")
request.user = SimpleLazyObject(lambda: get_user(request))
複製代碼
在前面提過，中間件的加載是按照必定順序（正反序）， AuthenticationMiddleware的process_request方法基於session中間件被加載過了，而後經過request的session，將用戶取出來放入到request.user 。
process_request 應該返回 None 或者 HTTPResponse 對象。當返回 None 時，WSGI handler 會繼續加載 process_request 裏面的方法，若是是後一種狀況，那麼Handlers會直接加載_response_middleware的列表，而後直接response。
解析 url
當_request_middleware列表中的 process_request 被遍歷完，會獲得一個通過處理的request對象（加入了request.session,request.user等屬性）。
django將按順序進行對url進行正則匹配，若是匹配不成功，就會拋出異常。若是request的中間件返回None，那麼Django會去解析用戶請求的URL。
在setting中有一個ROOT_URLCONF，它指向urls.py文件，根據這個文件能夠生產一個urlconf，本質上，他就是url與視圖函數之間的映射表，而後經過resolver解析用戶的url，找到第一個匹配的view。
process_view
通過url的匹配，會得到視圖函數以及相關參數。在調用view函數以前，django會先加載_view_middleware中的各個process_view方法。
逐個默認的中間件看了一遍，只看到csrf有這個方法
# 僞代碼
class CsrfViewMiddleware(object):
def process_view(self, request, callback, callback_args, callback_kwargs):
if getattr(request, 'csrf_processing_done', False):
return None
try:
csrf_token = _sanitize_token(
request.COOKIES[settings.CSRF_COOKIE_NAME])
# Use same token next time
request.META['CSRF_COOKIE'] = csrf_token
except KeyError:
csrf_token = None
if getattr(callback, 'csrf_exempt', False):
return None
pass
複製代碼
這個方法的做用是判斷cookiers中是否存在csrf的字段，若是不存在，會直接拋出異常，若是存在，返回None。 view中間件和requst中間件同樣，必須返回None或一個httpResponse,若是返回一個httpresponse，那麼Handlers會直接加載_response_middleware的列表，而後返回HttpResponse，那麼Handlers會直接加載_response_middleware的列表，而後直接response
執行view邏輯
view函數須要知足：
- 基於函數（FBV）或者基於類的（CVB）的視圖。
- 接受的參數第一個必須爲request，而且須要返回一個response對象。
若是視圖函數拋出一個異常，Handler 將會循環遍歷_exception_middleware 列表，若是有一個異常被拋出，後面的 process_exception 將不會被執行。
process_response
在這個階段，咱們獲得了一個 HTTPResponse 對象，這個對象多是 process_view 返回的，也多是視圖函數返回的。如今咱們將循環訪問響應中間件。這是中間件調整數據的最後的機會。舉個例子：
class XFrameOptionsMiddleware(object):
def process_response(self, request, response):
# Don't set it if it's already in the response
if response.get('X-Frame-Options') is not None:
return response
# Don't set it if they used @xframe_options_exempt
if getattr(response, 'xframe_options_exempt', False):
return response
response['X-Frame-Options'] = self.get_xframe_options_value(request,
response)
return response
複製代碼
XFrameOptionsMiddleware將X-Frame-Options加入到response當中，防止網站被嵌套、被劫持。
class CsrfViewMiddleware(object):
def process_response(self, request, response):
if getattr(response, 'csrf_processing_done', False):
return response
if not request.META.get("CSRF_COOKIE_USED", False):
return response
# Set the CSRF cookie even if it's already set, so we renew
# the expiry timer.
response.set_cookie(settings.CSRF_COOKIE_NAME,
request.META["CSRF_COOKIE"],
max_age=settings.CSRF_COOKIE_AGE,
domain=settings.CSRF_COOKIE_DOMAIN,
path=settings.CSRF_COOKIE_PATH,
secure=settings.CSRF_COOKIE_SECURE,
httponly=settings.CSRF_COOKIE_HTTPONLY
)
# Content varies with the CSRF cookie, so set the Vary header.
patch_vary_headers(response, ('Cookie',))
response.csrf_processing_done = True
return response
複製代碼
CsrfViewMiddleware在response中設置csrf cookies
最後
當response的中間件加載完，系統在返回以前會調用WSGI服務器端傳過來的start_response方法對象，初始化響應，而後進行response響應。
總結
本文重點在於：
- django啓動時，啓動了一個WSGIserver以及爲每一個請求的用戶生成一個handler。
- 理解WSGI協議，而且WSGIHandler這個類控制整個請求到響應的流程，以及整個流程的基本過程。
- 中間件的概念，以及每個process_request, process_response, process_view, process_exception方法在哪一個步驟發揮着什麼樣的做用。
- 中間價的執行時有順序的，request與view是按照順序去執行的，而response和exception是反序的，這一步實在WSGIHandler在加載到它的各個列表的時候完成的。
參考博客：
1，Django教程筆記：6、中間件middleware
2，作python Web開發你要理解：WSGI & uwsgi
3，從請求到響應 django 都作了哪些處理
4，django從請求到返回都經歷了什麼
- 1. 一次請求到響應的過程
- 2. Django的請求和響應
- 3. Django 從啓動到請求到響應全過程分析-入門版
- 4. DJANGO請求與響應
- 5. django 請求 與 響應
- 6. Django：（03）請求和響應
- 7. Django-請求與響應
- 8. Django---請求與響應
- 9. 從請求到響應 django 都作了哪些處理
- 10. http的請求和響應過程3
- 更多相關文章...
- • HTTP 請求方法 - HTTP 教程
- • 如何僞造ARP響應？ - TCP/IP教程
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • Java 8 Stream 教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 一次請求到響應的過程
- 2. Django的請求和響應
- 3. Django 從啓動到請求到響應全過程分析-入門版
- 4. DJANGO請求與響應
- 5. django 請求 與 響應
- 6. Django：（03）請求和響應
- 7. Django-請求與響應
- 8. Django---請求與響應
- 9. 從請求到響應 django 都作了哪些處理
- 10. http的請求和響應過程3