YOUI

process_request¶

process_request(self, request)¶

request is an HttpRequest object. This method is called on each request, before Django decides which view to execute.

process_request() should return either None or an HttpResponse object. If it returns None, Django will continue processing this request, executing any other middleware and, then, the appropriate view. If it returns an HttpResponse object, Django won't bother calling ANY other request, view or exception middleware, or the appropriate view; it'll return that HttpResponse. Response middleware is always called on every response.

process_view¶

process_view(self, request, view_func, view_args, view_kwargs)¶

request is an HttpRequest object. view_func is the Python function that Django is about to use. (It's the actual function object, not the name of the function as a string.) view_args is a list of positional arguments that will be passed to the view, and view_kwargs is a dictionary of keyword arguments that will be passed to the view. Neither view_args nor view_kwargs include the first view argument (request).

process_view() is called just before Django calls the view. It should return either None or an HttpResponse object. If it returns None, Django will continue processing this request, executing any other process_view() middleware and, then, the appropriate view. If it returns an HttpResponse object, Django won't bother calling ANY other request, view or exception middleware, or the appropriate view; it'll return that HttpResponse. Response middleware is always called on every response.

process_response¶

process_response(self, request, response)¶

request is an HttpRequest object. response is the HttpResponse object returned by a Django view.

process_response() must return an HttpResponse object. It could alter the given response, or it could create and return a brand-new HttpResponse.

Unlike the process_request() and process_view() methods, the process_response() method is always called, even if the process_request() and process_view() methods of the same middleware class were skipped because an earlier middleware method returned an HttpResponse (this means that your process_response() method cannot rely on setup done in process_request(), for example). In addition, during the response phase the classes are applied in reverse order, from the bottom up. This means classes defined at the end of MIDDLEWARE_CLASSES will be run first.

process_exception¶

process_exception(self, request, exception)¶

request is an HttpRequest object. exception is an Exception object raised by the view function.

Django calls process_exception() when a view raises an exception. process_exception() should return either None or an HttpResponse object. If it returns an HttpResponse object, the response will be returned to the browser. Otherwise, default exception handling kicks in.

Again, middleware are run in reverse order during the response phase, which includes process_exception. If an exception middleware return a response, the middleware classes above that middleware will not be called at all.

__init__¶

Most middleware classes won't need an initializer since middleware classes are essentially placeholders for the process_* methods. If you do need some global state you may use __init__ to set up. However, keep in mind a couple of caveats:

• Django initializes your middleware without any arguments, so you can't define __init__ as requiring any arguments.
• Unlike the process_* methods which get called once per request, __init__ gets called only once, when the web server starts up.

Guidelines¶

• Middleware classes don't have to subclass anything.
• The middleware class can live anywhere on your Python path. All Django cares about is that the MIDDLEWARE_CLASSES setting includes the path to it.
• Feel free to look at Django's available middleware for examples.
• If you write a middleware component that you think would be useful to other people, contribute to the community! Let us know, and we'll consider adding it to Django.

初始化:__init__(self)
如果中间件类定义了一个构造方法(即一个__init__方法)，它应该不使用参数(除了标准的slef)
出于性能考虑，中间件类在长时间运行的服务器过程中只初始化一次，这意味着你不能指望每次请求运行时调用__init__，
只有在服务器启动时调用一次
中间件类可能也使用初始化时间来删除它们本身而不是被安装，如果初始化时触发django.exceptions.MiddlewareNotUsed异
常，则Django将从中间件堆栈删除该中间件，你可能使用这点来检查中间件类依赖的一些软件，或者服务器是否运行在调试
模式下，或者任何其它可能让你想禁止中间件的类型的环境

请求预处理:process_request(self, request)
该方法在请求被接收和URL被解析来决定运行哪个视图之前立即调用，它传递你可能想修改的HttpRequest对象
process_request()应该返回None或者HttpResponse对象，如果它返回None，Django将继续处理该请求，执行任何其它的中间
件然后是合适的视图
如果请求中间件返回HttpResponse对象，Django将不会再调用其它任何中间件(任何类型)或者合适的视图，它将返回该应答

视图预处理:process_view(self, request, view, args, kwargs)
该方法在请求中间件运行后和URL被解析到一个视图后和视图实际上被调用之前被调用
传递给该视图的参数为:
Argument           Explanation
request            HttpRequest对象
view               Django将会调用来树立该请求的Python方法，它是实际上的方法对象本身，而不是方法名字符串
args               将被传递给视图的位置参数列表，不包括request参数(它一直是视图的第一个参数)
kwargs             将被传递给视图的关键字参数字典
像process_request()一样，process_view()应该返回None或者HttpResponse对象，如果它返回None，Django将继续处理请求
执行任何其它的视图中间件然后是合适的视图
如果视图中间件返回HttpResponse对象，Django将不会再调用其它任何中间件或者合适的视图，它将返回该应答

应答后处理:process_response(self, request, response)
该方法再视图方法已经调用和应答生成后调用，这是中间件修改应答输出的地方，输出压缩(见下)是应答中间件的一个显然
的应用
参数应该非常自明了--request是请求对象，response是从视图返回的应答对象
不像请求和视图中间件，它们可以返回None，process_response()必须返回一个HttpResponse对象，该应答可以是传递给该
方法的原始应答(可能被修改了)或者新的应答

异常后处理:process_exception(self, request, exception)
该方法只在出错并且视图触发不可捕获的异常时调用，不包括Http404异常，你可以使用这个钩子来发送错误通知，在一个日
志文件记录信息，或者甚至尝试自动恢复该错误
该方法的参数是我们一直处理的同样的request对象和视图方法触发的真正的Exception对象exception
process_exception()可能返回一个作为应答显示给浏览器的HttpResponse或者返回None来继续Django内建的异常处理

例子
Django自带一些中间件类--上面讨论了--它们是很好的例子，阅读它们的代码应该给你中间件的力量的好的感觉
你也可以在Django的wiki上找到一些社区贡献的例子:
http://code.djangoproject.com/wiki/ContributedMiddleware