第十五章 中间件

第 12 章中所有的 session 和 user 工具都籍由一小簇中间件实现(例如，由中间件设定

view 中可见的 request.session 和 request.user )。

第 13 章讨论的站点范围 cache 实际上也是由一个中间件实现，一旦该中间件发现与

view 相应的 response 已在缓存中，就不再调用对应的 view 函数。

第 14 章所介绍的 flatpages , redirects , 和 csrf 等应用也都是通过中间件组件来完成其魔法般的功能。

这一章将深入到中间件及其工作机制中，并阐述如何自行编写中间件。

什么是中间件

中间件组件是遵循特定 API 规则的简单 Python 类。在深入到该 API 规则的正式细节之前，先看一下下面这个非常简单的例子。

高流量的站点通常需要将 Django 部署在负载平衡 proxy(参见第 20 章)之后。这种方式将带来一些复杂性，其一就是每个 request 中的远程 IP 地址(request.META["REMOTE_IP"])将指向该负载平衡 proxy，而不是发起这个 request 的实际 IP。负载平衡 proxy 处理这个问题的方法在特殊的 X-Forwarded-For 中设置实际发起请求的 IP。

因此，需要一个小小的中间件来确保运行在 proxy 之后的站点也能够在

request.META["REMOTE_ADDR"] 中得到正确的 IP 地址：

class SetRemoteAddrFromForwardedFor(object): def process_request(self, request):

try:

real_ip = request.META['HTTP_X_FORWARDED_FOR'] except KeyError:

pass else:

# HTTP_X_FORWARDED_FOR can be a comma-separated list of IPs.

# Take just the first one. real_ip = real_ip.split(",")[0]

request.META['REMOTE_ADDR'] = real_ip

一旦安装了该中间件(参见下一节)，每个 request 中的 X-Forwarded-For 值都会被自动插入到 request.META['REMOTE_ADDR'] 中。这样，Django 应用就不需要关心自己是否位于负载平衡 proxy 之后；简单读取 request.META['REMOTE_ADDR'] 的方式在是否有 proxy 的情形下都将正常工作。

实际上，为针对这个非常常见的情形，Django 已将该中间件内置。它位于

django.middleware.http 中, 下一节将给出这个中间件相关的更多细节。

安装中间件

如果按顺序阅读本书，应当已经看到涉及到中间件安装的多个示例,因为前面章节的许多例子都需要某些特定的中间件。出于完整性考虑，下面介绍如何安装中间件。

要启用一个中间件，只需将其添加到配置模块的 MIDDLEWARE_CLASSES 元组中。在

MIDDLEWARE_CLASSES 中，中间件组件用字符串表示：指向中间件类名的完整 Python 路径。例如，下面是 django-admin.py startproject 创建的缺省 MIDDLEWARE_CLASSES :

MIDDLEWARE_CLASSES = (

'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware'

)

Django 项目的安装并不强制要求任何中间件，如果你愿意，MIDDLEWARE_CLASSES 可以为空。但我们建议启用 CommonMiddleware ，稍后做出解释。

这里中间件出现的顺序非常重要。在 request 和 view 的处理阶段，Django 按照

MIDDLEWARE_CLASSES 中出现的顺序来应用中间件，而在 response 和异常处理阶段，Django则按逆序来调用它们。也就是说，Django 将 MIDDLEWARE_CLASSES 视为 view 函数外层的顺序包装子：在 request 阶段按顺序从上到下穿过，而在 response 则反过来。关于 Django 处理阶段的详细信息，请参见第三章”Django 怎么处理一个请求: 完整细节”这一节。

中间件方法

现在，我们已经知道什么是中间件和怎么安装它，下面将介绍中间件类中可以定义的所有方法。

Initializer: init (self)

在中间件类中， __init () 方法用于执行系统范围的设置。

出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 一 次。也就是说

__init () 仅在服务进程启动的时候调用，而在针对单个 request 处理时并不执行。

对一个 middleware 而言，定义 __init__() 方法的通常原因是检查自身的必要性。如果

__init () 抛出异常 django.core.exceptions.MiddlewareNotUsed ,则 Django 将从

middleware 栈中移出该 middleware。可以用这个机制来检查 middleware 依赖的软件是否存在、服务是否运行于调试模式、以及任何其它环境因素。

在中间件中定义 __init () 方法时，除了标准的 self 参数之外，不应定义任何其它参数。

Request 预处理函数: process_request(self, request)

这个方法的调用时机在 Django 接收到 request 之后，但仍未解析 URL 以确定应当运行的 view之前。Django 向它传入相应的 HttpRequest 对象，以便在方法中修改。

process_request() 应当返回 None 或 HttpResponse 对象.

如果返回 None , Django 将继续处理这个 request,执行后续的中间件， 然后调用相应的 view.

如果返回 HttpResponse 对象, Django 将不再执行 任何 其它的中间件(而无视其种类)以及相应的 view。 Django 将立即返回该 HttpResponse .

View 预处理函数: process_view(self, request, view, args, kwargs)

这个方法的调用时机在 Django 执行完 request 预处理函数并确定待执行的 view 之后，但在

view 函数实际执行之前。

表 15-1 列出了传入到这个 View 预处理函数的参数。

如同 process_request() , process_view() 应当返回 None 或 HttpResponse 对象。

如果返回 None , Django 将继续处理这个 request ,执行后续的中间件， 然后调用相应的 view.

如果返回 HttpResponse 对象, Django 将不再执行 任何 其它的中间件(不论种类)以及相应的 view. Django 将立即返回该 HttpResponse .

Response 后处理函数: process_response(self, request, response)

这个方法的调用时机在 Django 执行 view 函数并生成 response 之后。这里，该处理器就能修改 response 的内容；一个常见的用途是内容压缩，如 gzip 所请求的 HTML 页面。

这个方法的参数相当直观: request 是 request 对象，而 response 则是从 view 中返回的

response 对象。

不同可能返回 None 的 request 和 view 预处理函数, process_response() 必须 返回

HttpResponse 对象. 这个 response 对象可以是传入函数的那一个原始对象(通常已被修改)，也可以是全新生成的。

Exception 后处理函数: process_exception(self, request, exception)

这个方法只有在request 处理过程中出了问题并且view 函数抛出了一个未捕获的异常时才会被调用。这个钩子可以用来发送错误通知，将现场相关信息输出到日志文件, 或者甚至尝试从错误中自动恢复。

这个函数的参数除了一贯的 request 对象之外，还包括 view 函数抛出的实际的异常对象

exception 。

process_exception() 应当返回 None 或 HttpResponse 对象.

如果返回 None , Django 将用框架内置的异常处理机制继续处理相应 request。

如果返回 HttpResponse 对象, Django 将使用该 response 对象，而短路框架内置的异常处理机制。