认证支持中间件
中间件类: django.contrib.auth.middleware.authenticationmiddleware . django.contrib.auth.middleware.authenticationmiddleware .
这个中间件激活认证支持功能. 它在每个传入的 httprequest 对象中添加代表当前登录用户的 request.user 属性。 it adds the request.user attribute, representing the currently logged-in user, to every incoming httprequest object.
通用中间件
middleware class: django.middleware.common.commonmiddleware .
这个中间件为完美主义者提供了一些便利:
    禁止 ``disallowed_user_agents`` 列表中所设置的user agent访问 ：一旦提供，这一列表应当由已编译的正则表达式对象组成，这些对象用于匹配传入的request请求头中的user-agent域。 下面这个例子来自某个配置文件片段：
import redisallowed_user_agents = ( re.compile(r'^omniexplorer_bot'), re.compile(r'^googlebot'))
请注意 import re ,因为 disallowed_user_agents 要求其值为已编译的正则表达式(也就是 re.compile() 的返回值)。     依据 ``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上。 will be redirected to the same url with a leading www..     这两个选项都是为了规范化url。 其后的哲学是每个url都应且只应当存在于一处。 技术上来说，url example.com/bar 与 example.com/bar/ 及 www.example.com/bar/ 都互不相同。     依据 ``use_etags`` 的设置处理etag : etags 是http级别上按条件缓存页面的优化机制。 如果 use_etags 为 true ，django针对每个请求以md5算法处理页面内容，从而得到etag, 在此基础上，django将在适当情形下处理并返回 not modified 回应(译注：     请注意，还有一个条件化的 get 中间件, 处理etags并干得更多，下面马上就会提及。压缩中间件
中间件类 django.middleware.gzip.gzipmiddleware .
这个中间件自动为能处理gzip压缩(包括所有的现代浏览器)的浏览器自动压缩返回]内容。 这将极大地减少web服务器所耗用的带宽。 代价是压缩页面需要一些额外的处理时间。
相对于带宽，人们一般更青睐于速度，但是如果你的情形正好相反，尽可启用这个中间件。
条件化的get中间件
middleware class: django.middleware.http.conditionalgetmiddleware .
这个中间件对条件化 get 操作提供支持。 如果response头中包括 last-modified 或 etag 域，并且request头中包含 if-none-match 或 if-modified-since 域，且两者一致，则该response将被response 304(not modified)取代。 对 etag 的支持依赖于 use_etags 配置及事先在response头中设置 etag 域。稍前所讨论的通用中间件可用于设置response中的 etag 域。 as discussed above, the etag header is set by the common middleware.
此外，它也将删除处理 head request时所生成的response中的任何内容，并在所有request的response头中设置 date 和 content-length 域。
反向代理支持 (x-forwarded-for中间件)
middleware class: django.middleware.http.setremoteaddrfromforwardedfor .
这是我们在 什么是中间件 这一节中所举的例子。 在 request.meta['http_x_forwarded_for'] 存在的前提下，它根据其值来设置 request.meta['remote_addr'] 。在站点位于某个反向代理之后的、每个request的 remote_addr 都被指向 127.0.0.1 的情形下，这一功能将非常有用。 it sets request.meta['remote_addr'] based on request.meta['http_x_forwarded_for'] , if the latter is set. this is useful if you're sitting behind a reverse proxy that causes each request's remote_addr to be set to 127.0.0.1 .
红色警告！
这个middleware并 不 验证 http_x_forwarded_for 的合法性。
如果站点并不位于自动设置 http_x_forwarded_for 的反向代理之后，请不要使用这个中间件。 否则，因为任何人都能够伪造 http_x_forwarded_for 值，而 remote_addr 又是依据 http_x_forwarded_for 来设置，这就意味着任何人都能够伪造ip地址。
只有当能够绝对信任 http_x_forwarded_for 值得时候才能够使用这个中间件。
会话支持中间件
middleware class: django.contrib.sessions.middleware.sessionmiddleware .
这个中间件激活会话支持功能.
middleware classes: django.middleware.cache.updatecachemiddleware and django.middleware.cache.fetchfromcachemiddleware .
这些中间件互相配合以缓存每个基于django的页面。
事务处理中间件
middleware class: django.middleware.transaction.transactionmiddleware .
这个中间件将数据库的 commit 或 rollback 绑定到request/response处理阶段。 如果view函数成功执行，则发出 commit 指令。 如果view函数抛出异常，则发出 rollback 指令。
这个中间件在栈中的顺序非常重要。 其外层的中间件模块运行在django缺省的 保存-提交 行为模式下。 而其内层中间件(在栈中的其后位置出现)将置于与view函数一致的事务机制的控制下。