Django源码分析(二)--middleware

Django源码分析(二)–中间件

接上回, Django启动时会创建一个WSGIHandler实例

# django\core\handlers\wsgi.py
class WSGIHandler(base.BaseHandler):
    request_class = WSGIRequest

    def __init__(self, *args, **kwargs):
        super(WSGIHandler, self).__init__(*args, **kwargs)
        self.load_middleware()

# django\core\handlers\base.py
class BaseHandler(object):

    def __init__(self):
        # 初始化 Django 的中间件
        self._request_middleware = None
        self._view_middleware = None
        self._template_response_middleware = None
        self._response_middleware = None
        self._exception_middleware = None
        self._middleware_chain = None
    
    def load_middleware(self):
        """
        Populate middleware lists from settings.MIDDLEWARE (or the deprecated
        MIDDLEWARE_CLASSES).

        Must be called after the environment is fixed (see __call__ in subclasses).
        """
        self._request_middleware = []
        self._view_middleware = []
        self._template_response_middleware = []
        self._response_middleware = []
        self._exception_middleware = []
        handler = convert_exception_to_response(self._get_response)

        # 根据settings.MIDDLEWARE中的列表，加载中间件
        for middleware_path in reversed(settings.MIDDLEWARE):
            ...

可以看到, load_middleware 会去加载 settings 中的 MIDDLEWARE, 就是下面这个列表:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

然后遍历里面的元素, 然后根据里面实现的方法把它们加到对应的 list中:

    if hasattr(mw_instance, 'process_view'):
        self._view_middleware.insert(0, mw_instance.process_view)
    if hasattr(mw_instance, 'process_template_response'):
        self._template_response_middleware.append(mw_instance.process_template_response)
    if hasattr(mw_instance, 'process_exception'):
        self._exception_middleware.append(mw_instance.process_exception)

handler = convert_exception_to_response(mw_instance)

当接收到 request 时, 不同的阶段就会调用对应的方法。

来看一下所谓的 middleware 到底是什么:

# django\middleware\common.py
class CommonMiddleware(MiddlewareMixin):
    response_redirect_class = http.HttpResponsePermanentRedirect

    def process_request(self, request):
        ...
    def process_response(self, request, response):
        ...


# django\utils\deprecation.py
class MiddlewareMixin(object):
    def __init__(self, get_response=None):
        self.get_response = get_response
        super(MiddlewareMixin, self).__init__()

    def __call__(self, request):
        response = None
        if hasattr(self, 'process_request'):
            response = self.process_request(request)
        if not response:
            response = self.get_response(request)
        if hasattr(self, 'process_response'):
            response = self.process_response(request, response)
        return response

中间件的顺序和层次

在请求(request)阶段，调用视图之前，Django 会按照 MIDDLEWARE 中定义的顺序自顶向下应用中间件。会用到两个钩子。

process_request()

process_view()

在响应( response)阶段，调用视图之后，中间件会按照相反的顺序应用，自底向上。会用到三个钩子：

process_excpetion()

process_template_response()

process_response()

你可以把它想象成一颗洋葱：每个中间件都是包裹视图的一层’皮’，而视图就是洋葱心。如果 request 通过洋葱的各层(每层通过调用 get_response 传递 request 到下一层)，传向中心的视图，response 会原路返回穿过各层。

如果某一次决定短路直接返回 response (不再调用 get_response )，余下的各层和视图将不会见到任何 request 和 response。