Django开发——中间件

有些场合，需要对Django处理的每个request都执行某段代码，这类代码可能是在view处理之前修改传入的request，或者记录日志信息以便用于调试。这类功能可以用Django的中间件框架来实现。
安装中间件
要启用一个中间件，只需将其添加到配置模块的MIDDLEWARE中，其中中间件用字符表示：指向中间件雷鸣的完整Python路径。这里中间件出现的顺序非常重要。在request和view的处理阶段，Django按照MIDDLEWARE中出现的顺序来应用中间件，而在request和异常处理阶段，Django则按逆序来调用它们。也就是说Django将MIDDLEWARE时为view函数外层的顺序包装：在request阶段按顺序从上到下，而response则反过来。

中间件方法

Initializer:_init_(self)[初始化]
用于执行系统范围的设置。出与性能的考虑。每个已启用的中间件在每个服务器进程中只初始化一次，所以，_init_()仅在服务进程启动时候调用，而在针对单个request处理时并不执行。定义_init_()方法的通常原因是检查自身的必要性。
Requesth预处理函数:process_request(self,request)
这个方法的调用时机在Django接收到request之后，但未解析URL以确定应当运行的view之前。Django向它传入相应的HttpRequest对象，以便在方法中修改。

如果返回None，Django将继续处理这个request执行后续的中间件，然后调用相应的view。
如果返回HttpResponse对象，Django将不再执行任何其他中间件以及相应的view。Django将立即返回该HttpResponse。

View预处理函数: process_view(self, request, view, args, kwargs)
这个方法的调用时机在Django执行完request预处理函数并确定待执行的view之后，但在view函数实际执行之前。
* 如果返回None，Django将继续处理这个request执行后续的，然后调用相应的view。
* 如果返回HttpResponse对象，Django将不再执行任何其他中间件以及相应的view。Django将立即返回该HttpResponse。

Response后处理函数: process_response(self, request, response)
这个方法调用时机在Django执行view函数并生成response之后。
request是request对象，而response则是从view中返回的response对象。必须返回HttpRequest对象，这个response对象可以是传入函数的那一个原始对象，也可以是全新生成的。
Exception后处理函数: process_exception(self, request, exception)
这个方法只有在requst处理过程中出了问题并且view函数跑出一个未捕获的异常时才会会被调用。这个钩子可以用来发送错误通知，将现场相关信息输出到日志文件，或者甚至尝试从错误中自动恢复。

如果返回None，Django将用框架内置的异常处理机制继续处理相应request；
如果返回HttpResponse对象，Django将使用该response对象，而短路框架内置得一回藏处理机制。

内置的中间件

认证中间件
中间件类: django.contrib.auth.middleware.AuthenticationMiddleware .
这个中加件激活认证支持功能，他在每个传入的HttpRequest对象中添加代表当前登录用户的request.user属性。
通用中间件
Middleware class: django.middleware.common.CommonMiddleware
禁止”DISALLOWED_USER_AGENTS”列表中所设置的user agent访问：一旦提供，这一列表应当由已编译的正则表达式对象组成，这些对象用于匹配传入的request请求头中的user-agent域。

import re
DISALLOWED_USER_AGENTS = (
re.compile(r'^OmniExplorer_Bot'),
re.compile(r'^Googlebot')
)

依据“APPEND_SLASH”和”PREPEND_WWW”的设置执行URL重写:如果APPEND_SLASH为True，那些尾部没有斜杠的URL将被重定向到添加了斜杠的相应URL，除非path的最末组成部分包含点号。如foo.com/bar 会被重定向到 foo.com/bar/ , 但是 foo.com/bar/file.txt 将以不变形式通过。
如果PREPEND_WWW为True，那些缺少先导www.的URLs将会被重定向到含有先导www.相应URL上。
这两个选项都是为了规范化URL。
依据”USE_ETAGS”的设置处理Etag：ETags是HTTP级别上按条件缓存页面的优化机制。如果user_ETAGS为True，D激昂哦针对每个请求以MD5算法处理页面内容，从而得到Etag，在此基础上，Django将在适当情形下处理并返回Not Modified回应。
压缩中间件
django.middleware.gzip.GZipMiddleware
这个中间件自动为能处理gzip压缩的浏览器自动压缩返回内容。这将极大地减少Web服务器所耗用的带宽。代价是压缩页面需要一些额外的处理时间。
条件化GET中间件
django.middleware.http.ConditionalGetMiddleware

这个中间件对条件化GET操作提供支持。如果response头中包括Last-Modified或ETag域，并且request头中包含If‐None‐Match 或 If‐Modified‐Since 域，且两者以只，则该response将被response 304取代。此外它也将删除处理HEAD request时所生成的response中的任何内容，并在所有request的response头中设置Date和Content-Length域。
反向代理
在 request.META[‘HTTP_X_FORWARDED_FOR’] 存在的前提下,
它根据其值来设置 request.META[‘REMOTE_ADDR’] 。在站点位于某个反向代理之后的、每个request的REMOTE_ADDR 都被指向 127.0.0.1 的情形下,这一功能将非常有用。
这个中间件并不验证HTTP_X_FORWARDED_FOR的合法性。如果站点并不位于自动设置HTTP_X_FORWARDED_FOR的反向代理之后，请不要使用这个中间件。否则，因为任何人都能伪造HTTP_X_FORWARDED_FOR的值，而REMOTE_ADDR来设置，这意味着任何人都能伪造IP地址，只有当能够绝对信任HTTP_X_FORWARDED_FOR值的时候才能够使用。
会话支持中间件
django.contrib.sessions.middleware.SessionMiddleware
激活会话支持功能
站点支持中间件
django.middleware.cache.UpdateCacheMiddleware
django.middleware.cache.FetchFromCacheMiddleware
这些中间件互相配合以缓存每个基于Django的页面。
事务处理中间件
django.middleware.transaction.TransactionMiddleware
这个中间件将数据库的COMMT或ROLLBACK绑定到request/response处理阶段。如果view函数成功执行。则发出COMMIT指令。如果view函数抛出异常，则发出BOLLBACK指令。这个中间件在栈中的顺序非常重要。其外层的中间件模块运行在Django缺省的保存——提交行为模式下，而其内层中间件爱你将置于与view函数一致的事务机制的控制下。