django從請求到響應的過程深入講解
django啟動
我們在啟動一個django項目的時候,無論你是在命令行執(zhí)行還是在pycharm直接點擊運行,其實都是執(zhí)行'runserver'的操作,而ruserver是使用django自帶的的web server,主要用于開發(fā)和調(diào)試中,而在正式的環(huán)境中,一般會使用nginx+uwsgi模式。
無論是哪種方式,當啟動一個項目,都會做2件事:
- 創(chuàng)建一個WSGIServer類的實例,接受用戶的請求。
- 當一個用戶的http請求到達的時,為用戶指定一個WSGIHandler,用于處理用戶請求與響應,這個Handler是處理整個request的核心。
WSGI
WSGI:全稱是Web Server Gateway Interface,WSGI不是服務器,也不用于與程序交互的API,更不是代碼,而只是定義了一個接口,用于描述web server如何與web application通信的規(guī)范。
當客戶端發(fā)送一次請求后,最先處理請求的實際上是 web 服務器就是我們經(jīng)常說的 nginx、Apache 這類的 web 服務器,然后web服務器再把請求交給web應用程序(如django)處理,這中間的中介就是WSGI,它把 web 服務器和 web 框架 (Django) 連接起來。

簡單介紹一下WSGI的一些內(nèi)容,它規(guī)定應用是可調(diào)用對象(函數(shù)/方法),然后它接受2個固定參數(shù):一個是含有服務器端的環(huán)境變量,另一個是可調(diào)用對象,這個對象用來初始化響應,給響應加上status code狀態(tài)碼和httpt頭部,并且返回一個可調(diào)用對象??梢钥磦€簡單的例子
# 這段代碼來自python核心編程
def simplr_wsgi_app(environ, start_response):
# 固定兩個參數(shù),django中也使用同樣的變量名
status = '200 OK'
headers = [{'Content-type': 'text/plain'}]
# 初始化響應, 必須在返回前調(diào)用
start_response(status, headers)
# 返回可迭代對象
return ['hello world!']
django中,實現(xiàn)同樣邏輯的是通過WSGIHandler這個類,下面我們也會重點介紹它!
如果對WSGI與uWSGI有興趣的,推薦大家看這篇文章,WSGI & uwsgi ,大贊!
中間件基本概念
顧名思義,中間件是位于Web服務器端和Web應用之間的,它可以添加額外的功能。當我們創(chuàng)建一個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', ]
中間件要么對來自用戶的數(shù)據(jù)進行預處理,然后發(fā)送給應用;要么在應用將響應負載返回給用戶之前,對結果數(shù)據(jù)進行一些最終的調(diào)整。通俗一點,在django中,中間能夠幫我們準備好request這個對象,然后應用可以直接使用request對象獲取到各類數(shù)據(jù),也幫我們將response添加頭部,狀態(tài)碼等。
數(shù)據(jù)流
當django接受到一個請求時,會初始化一個WSGIHandler,可以在項目下的wsgi.py文件進行跟蹤,你就會發(fā)現(xiàn)這一個類。
class WSGIHandler(base.BaseHandler): def __call__(self, environ, start_response): pass
這個類遵循WSGI應用的規(guī)定,它接受2個參數(shù):一個是含有服務器端的環(huán)境變量,另一個是可調(diào)用對象,返回一個可迭代對象。
這個handler控制了從請求到響應的整個過程,主要流程:

在網(wǎng)上看到另外一張圖,更為完整:

大致幾個步驟:
1. 用戶通過瀏覽器請求一個頁面
2. 請求到達Request Middlewares,中間件對request做一些預處理或者直接response請求
3. URLConf通過urls.py文件和請求的URL找到相應的View
4. View Middlewares被訪問,它同樣可以對request做一些處理或者直接返回response
5. 調(diào)用View中的函數(shù)
6. View中的方法可以選擇性的通過Models訪問底層的數(shù)據(jù)
7. 所有的Model-to-DB的交互都是通過manager完成的
8. 如果需要,Views可以使用一個特殊的Context
9. Context被傳給Template用來生成頁面
a.Template使用Filters和Tags去渲染輸出
b.輸出被返回到View
c.HTTPResponse被發(fā)送到Response Middlewares
d.任何Response Middlewares都可以豐富response或者返回一個完全不同的response
e.Response返回到瀏覽器,呈現(xiàn)給用戶
中間類中的順序與方法
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的執(zhí)行加載順序正好是相反,在循環(huán)中,process_request是被append到列表的末尾,而process_request是被insert到最前面的。

(可能有些情況Comment中間件在Session前面,了解加載的順序就好了)
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 會繼續(xù)加載 process_request 里面的方法,如果是后一種情況,那么Handlers會直接加載_response_middleware的列表,然后直接response。
解析 url
當_request_middleware列表中的 process_request 被遍歷完,會得到一個經(jīng)過處理的request對象(加入了request.session,request.user等屬性)。
django將按順序進行對url進行正則匹配,如果匹配不成功,就會拋出異常。如果request的中間件返回None,那么Django會去解析用戶請求的URL。
在setting中有一個ROOT_URLCONF,它指向urls.py文件,根據(jù)這個文件可以生產(chǎn)一個urlconf,本質(zhì)上,他就是url與視圖函數(shù)之間的映射表,然后通過resolver解析用戶的url,找到第一個匹配的view。
process_view
經(jīng)過url的匹配,會獲得視圖函數(shù)以及相關參數(shù)。在調(diào)用view函數(shù)之前,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
執(zhí)行view邏輯
view函數(shù)需要滿足:
- 基于函數(shù)(FBV)或者基于類的(CVB)的視圖。
- 接受的參數(shù)第一個必須為request,并且需要返回一個response對象。
如果視圖函數(shù)拋出一個異常,Handler 將會循環(huán)遍歷_exception_middleware 列表,如果有一個異常被拋出,后面的 process_exception 將不會被執(zhí)行。
process_response
在這個階段,我們得到了一個 HTTPResponse 對象,這個對象可能是 process_view 返回的,也可能是視圖函數(shù)返回的。現(xiàn)在我們將循環(huán)訪問響應中間件。這是中間件調(diào)整數(shù)據(jù)的最后的機會。舉個例子:
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當中,防止網(wǎng)站被嵌套、被劫持。
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的中間件加載完,系統(tǒng)在返回之前會調(diào)用WSGI服務器端傳過來的start_response方法對象,初始化響應,然后進行response響應。
總結
本文重點在于:
- django啟動時,啟動了一個WSGIserver以及為每個請求的用戶生成一個handler。
- 理解WSGI協(xié)議,并且WSGIHandler這個類控制整個請求到響應的流程,以及整個流程的基本過程。
- 中間件的概念,以及每一個process_request, process_response, process_view, process_exception方法在哪個步驟發(fā)揮著什么樣的作用。
- 中間價的執(zhí)行時有順序的,request與view是按照順序去執(zhí)行的,而response和exception是反序的,這一步實在WSGIHandler在加載到它的各個列表的時候完成的。
好了,以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
參考博客:
1,Django教程筆記:六、中間件middleware
2,做python Web開發(fā)你要理解:WSGI & uwsgi
3,從請求到響應 django 都做了哪些處理
4,django從請求到返回都經(jīng)歷了什么
相關文章
利用一個簡單的例子窺探CPython內(nèi)核的運行機制
這篇文章主要介紹了利用一個簡單的例子窺探CPython內(nèi)核的運行機制,作者通過一個簡單的輸出函數(shù)深入、介紹了CPython源碼C代碼中的一些函數(shù),需要的朋友可以參考下2015-03-03
Python OpenCV調(diào)用攝像頭檢測人臉并截圖
這篇文章主要為大家詳細介紹了Python OpenCV調(diào)用攝像頭檢測人臉并截圖,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2019-07-07
Python使用Flask編寫一個網(wǎng)站的代碼指南
使用Flask編寫一個網(wǎng)站是一個相對簡單且有趣的過程,Flask是一個用Python編寫的輕量級Web應用框架,它易于上手,同時也非常強大,適合構建從簡單的博客到復雜的Web應用的各種項目,以下是一個使用Flask編寫簡單網(wǎng)站的指南,包括代碼示例,需要的朋友可以參考下2024-11-11

