django啟動(dòng)

我們在啟動(dòng)一個(gè)django項(xiàng)目的時(shí)候，無論你是在命令行執(zhí)行還是在pycharm直接點(diǎn)擊運(yùn)行，其實(shí)都是執(zhí)行'runserver'的操作，而ruserver是使用django自帶的的web server，主要用于開發(fā)和調(diào)試中，而在正式的環(huán)境中，一般會(huì)使用nginx+uwsgi模式。

無論是哪種方式，當(dāng)啟動(dòng)一個(gè)項(xiàng)目，都會(huì)做2件事：

• 創(chuàng)建一個(gè)WSGIServer類的實(shí)例，接受用戶的請求。
• 當(dāng)一個(gè)用戶的http請求到達(dá)的時(shí)，為用戶指定一個(gè)WSGIHandler，用于處理用戶請求與響應(yīng)，這個(gè)Handler是處理整個(gè)request的核心。

WSGI

WSGI：全稱是Web Server Gateway Interface，WSGI不是服務(wù)器，也不用于與程序交互的API，更不是代碼，而只是定義了一個(gè)接口，用于描述web server如何與web application通信的規(guī)范。
當(dāng)客戶端發(fā)送一次請求后，最先處理請求的實(shí)際上是 web 服務(wù)器就是我們經(jīng)常說的 nginx、Apache 這類的 web 服務(wù)器，然后web服務(wù)器再把請求交給web應(yīng)用程序(如django)處理，這中間的中介就是WSGI，它把 web 服務(wù)器和 web 框架 (Django) 連接起來。

簡單介紹一下WSGI的一些內(nèi)容，它規(guī)定應(yīng)用是可調(diào)用對象(函數(shù)/方法)，然后它接受2個(gè)固定參數(shù)：一個(gè)是含有服務(wù)器端的環(huán)境變量，另一個(gè)是可調(diào)用對象，這個(gè)對象用來初始化響應(yīng)，給響應(yīng)加上status code狀態(tài)碼和httpt頭部，并且返回一個(gè)可調(diào)用對象。可以看個(gè)簡單的例子

# 這段代碼來自python核心編程
def simplr_wsgi_app(environ, start_response):
 # 固定兩個(gè)參數(shù)，django中也使用同樣的變量名
 status = '200 OK'
 headers = [{'Content-type': 'text/plain'}]
 # 初始化響應(yīng), 必須在返回前調(diào)用
 start_response(status, headers)
 # 返回可迭代對象
 return ['hello world!']

django中，實(shí)現(xiàn)同樣邏輯的是通過WSGIHandler這個(gè)類，下面我們也會(huì)重點(diǎn)介紹它！

如果對WSGI與uWSGI有興趣的，推薦大家看這篇文章，WSGI & uwsgi ，大贊！

中間件基本概念

顧名思義，中間件是位于Web服務(wù)器端和Web應(yīng)用之間的，它可以添加額外的功能。當(dāng)我們創(chuàng)建一個(gè)django項(xiàng)目(通過pycharm)，它會(huì)自動(dòng)幫我們設(shè)置一些必要的中間件。

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ù)進(jìn)行預(yù)處理，然后發(fā)送給應(yīng)用；要么在應(yīng)用將響應(yīng)負(fù)載返回給用戶之前，對結(jié)果數(shù)據(jù)進(jìn)行一些最終的調(diào)整。通俗一點(diǎn)，在django中，中間能夠幫我們準(zhǔn)備好request這個(gè)對象，然后應(yīng)用可以直接使用request對象獲取到各類數(shù)據(jù)，也幫我們將response添加頭部，狀態(tài)碼等。

數(shù)據(jù)流

當(dāng)django接受到一個(gè)請求時(shí)，會(huì)初始化一個(gè)WSGIHandler，可以在項(xiàng)目下的wsgi.py文件進(jìn)行跟蹤，你就會(huì)發(fā)現(xiàn)這一個(gè)類。

class WSGIHandler(base.BaseHandler):
 def __call__(self, environ, start_response):
 pass

這個(gè)類遵循WSGI應(yīng)用的規(guī)定，它接受2個(gè)參數(shù)：一個(gè)是含有服務(wù)器端的環(huán)境變量，另一個(gè)是可調(diào)用對象，返回一個(gè)可迭代對象。

這個(gè)handler控制了從請求到響應(yīng)的整個(gè)過程，主要流程：

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

大致幾個(gè)步驟：

1. 用戶通過瀏覽器請求一個(gè)頁面 

2. 請求到達(dá)Request Middlewares，中間件對request做一些預(yù)處理或者直接response請求 

3. URLConf通過urls.py文件和請求的URL找到相應(yīng)的View 

4. View Middlewares被訪問，它同樣可以對request做一些處理或者直接返回response 

5. 調(diào)用View中的函數(shù) 

6. View中的方法可以選擇性的通過Models訪問底層的數(shù)據(jù) 

7. 所有的Model-to-DB的交互都是通過manager完成的 

8. 如果需要，Views可以使用一個(gè)特殊的Context 

9. Context被傳給Template用來生成頁面  

    a.Template使用Filters和Tags去渲染輸出  

    b.輸出被返回到View  

    c.HTTPResponse被發(fā)送到Response Middlewares  

    d.任何Response Middlewares都可以豐富response或者返回一個(gè)完全不同的response  

    e.Response返回到瀏覽器，呈現(xiàn)給用戶 

中間類中的順序與方法

django 的中間件類至少含有以下四個(gè)方法中的一個(gè)：
process_request、 process_view、process_exception、process_response
WSGIHandler通過load_middleware將這個(gè)些方法分別添加到_request_middleware、_view_middleware、_response_middleware 和 _exception_middleware四個(gè)列表中。

并不是每個(gè)中間件都有這4個(gè)方法，如果不存在某個(gè)方法，那么在加載的過程中，這個(gè)類就被跳過。

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

舉幾個(gè)中間件的例子

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 應(yīng)該返回 None 或者 HTTPResponse 對象。當(dāng)返回 None 時(shí)，WSGI handler 會(huì)繼續(xù)加載 process_request 里面的方法，如果是后一種情況，那么Handlers會(huì)直接加載_response_middleware的列表，然后直接response。

解析 url

當(dāng)_request_middleware列表中的 process_request 被遍歷完，會(huì)得到一個(gè)經(jīng)過處理的request對象（加入了request.session,request.user等屬性）。

django將按順序進(jìn)行對url進(jìn)行正則匹配，如果匹配不成功，就會(huì)拋出異常。如果request的中間件返回None，那么Django會(huì)去解析用戶請求的URL。

在setting中有一個(gè)ROOT_URLCONF，它指向urls.py文件，根據(jù)這個(gè)文件可以生產(chǎn)一個(gè)urlconf，本質(zhì)上，他就是url與視圖函數(shù)之間的映射表，然后通過resolver解析用戶的url，找到第一個(gè)匹配的view。

process_view

經(jīng)過url的匹配，會(huì)獲得視圖函數(shù)以及相關(guān)參數(shù)。在調(diào)用view函數(shù)之前，django會(huì)先加載_view_middleware中的各個(gè)process_view方法。

逐個(gè)默認(rèn)的中間件看了一遍，只看到csrf有這個(gè)方法

# 偽代碼
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

這個(gè)方法的作用是判斷cookiers中是否存在csrf的字段，如果不存在，會(huì)直接拋出異常，如果存在，返回None。
view中間件和requst中間件一樣，必須返回None或一個(gè)httpResponse,如果返回一個(gè)httpresponse，那么Handlers會(huì)直接加載_response_middleware的列表，然后返回HttpResponse，那么Handlers會(huì)直接加載_response_middleware的列表，然后直接response

執(zhí)行view邏輯

view函數(shù)需要滿足：

1. 基于函數(shù)（FBV）或者基于類的（CVB）的視圖。
2. 接受的參數(shù)第一個(gè)必須為request，并且需要返回一個(gè)response對象。

如果視圖函數(shù)拋出一個(gè)異常，Handler 將會(huì)循環(huán)遍歷_exception_middleware 列表，如果有一個(gè)異常被拋出，后面的 process_exception 將不會(huì)被執(zhí)行。

process_response

在這個(gè)階段，我們得到了一個(gè) HTTPResponse 對象，這個(gè)對象可能是 process_view 返回的，也可能是視圖函數(shù)返回的。現(xiàn)在我們將循環(huán)訪問響應(yīng)中間件。這是中間件調(diào)整數(shù)據(jù)的最后的機(jī)會(huì)。舉個(gè)例子：

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當(dāng)中，防止網(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中設(shè)置csrf cookies

最后

當(dāng)response的中間件加載完，系統(tǒng)在返回之前會(huì)調(diào)用WSGI服務(wù)器端傳過來的start_response方法對象，初始化響應(yīng)，然后進(jìn)行response響應(yīng)。

總結(jié)

本文重點(diǎn)在于：

1. django啟動(dòng)時(shí)，啟動(dòng)了一個(gè)WSGIserver以及為每個(gè)請求的用戶生成一個(gè)handler。
2. 理解WSGI協(xié)議，并且WSGIHandler這個(gè)類控制整個(gè)請求到響應(yīng)的流程，以及整個(gè)流程的基本過程。
3. 中間件的概念，以及每一個(gè)process_request, process_response, process_view, process_exception方法在哪個(gè)步驟發(fā)揮著什么樣的作用。
4. 中間價(jià)的執(zhí)行時(shí)有順序的，request與view是按照順序去執(zhí)行的，而response和exception是反序的，這一步實(shí)在WSGIHandler在加載到它的各個(gè)列表的時(shí)候完成的。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

參考博客：

  1，Django教程筆記：六、中間件middleware
  2，做python Web開發(fā)你要理解：WSGI & uwsgi
  3，從請求到響應(yīng) django 都做了哪些處理  
  4，django從請求到返回都經(jīng)歷了什么

最新評論