django從請求到響應的過程

__奇犽犽發表於2018-01-29
Django

1月30號進行修改，本文原本寫著轉載，到後來發現本文存在一些邏輯錯誤，又再參考了另外幾篇文章，重新更新了一下文章，文末會附幾篇參考文章的地址，有興趣的讀者可以點進去看。

django啟動

我們在啟動一個django專案的時候，無論你是在命令列執行還是在pycharm直接點選執行，其實都是執行'runserver'的操作，而ruserver是使用django自帶的的web server，主要用於開發和除錯中，而在正式的環境中，一般會使用nginx+uwsgi模式。

無論是哪種方式，當啟動一個專案，都會做2件事：

  • 建立一個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) 連線起來。

這裡寫圖片描述
簡單介紹一下WSGI的一些內容，它規定應用是可呼叫物件(函式/方法)，然後它接受2個固定引數：一個是含有伺服器端的環境變數，另一個是可呼叫物件，這個物件用來初始化響應，給響應加上status code狀態碼和httpt頭部，並且返回一個可呼叫物件。可以看個簡單的例子

# 這段程式碼來自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新增頭部，狀態碼等。

資料流

當django接受到一個請求時，會初始化一個WSGIHandler，可以在專案下的wsgi.py檔案進行跟蹤，你就會發現這一個類。

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

複製程式碼

這個類遵循WSGI應用的規定，它接受2個引數：一個是含有伺服器端的環境變數，另一個是可呼叫物件，返回一個可迭代物件。 這個handler控制了從請求到響應的整個過程，主要流程：

handler

在網上看到另外一張圖，更為完整：

handler2

大致幾個步驟：
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到最前面的。

middleware
（可能有些情況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 會繼續載入 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函式需要滿足：

  1. 基於函式（FBV）或者基於類的（CVB）的檢視。
  2. 接受的引數第一個必須為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響應。

總結

本文重點在於：

  1. django啟動時，啟動了一個WSGIserver以及為每個請求的使用者生成一個handler。
  2. 理解WSGI協議，並且WSGIHandler這個類控制整個請求到響應的流程，以及整個流程的基本過程。
  3. 中介軟體的概念，以及每一個process_request, process_response, process_view, process_exception方法在哪個步驟發揮著什麼樣的作用。
  4. 中間價的執行時有順序的，request與view是按照順序去執行的，而response和exception是反序的，這一步實在WSGIHandler在載入到它的各個列表的時候完成的。

參考部落格：
  1，Django教程筆記：六、中介軟體middleware
  2，做python Web開發你要理解：WSGI & uwsgi
  3，從請求到響應 django 都做了哪些處理  
  4，django從請求到返回都經歷了什麼

相關文章