【转】请求处理机制其一：进入Django前的准备

一个 Request 到达了！

首先发生的是一些和 Django 有关（前期准备）的其他事情，分别是：

如果是 Apache/mod_python 提供服务，request 由 mod_python 创建的 django.core.handlers.modpython.ModPythonHandler 实例传递给 Django。
如果是其他服务器，则必须兼容 WSGI，这样，服务器将创建一个 django.core.handlers.wsgi.WsgiHandler 实例。

这两个类都继承自 django.core.handlers.base.BaseHandler，它包含对任何类型的 request 来说都需要的公共代码。

快准备处理器(Handler)

当上面其中一个处理器实例化后，紧接着发生了一系列的事情：

这个处理器（handler）导入你的 Django 配置文件。
这个处理器导入 Django 的自定义异常类。
这个处理器调用它自己的 load_middleware 方法，加载所有列在 MIDDLEWARE_CLASSES 中的 middleware 类并且内省它们。

最后一条有点复杂，我们仔细瞧瞧。

一个 middleware 类可以渗入处理过程的四个阶段：request，view，response 和 exception。要做到这一点，只需要定义指定的、恰当的方法：process_request，process_view， process_response 和 process_exception。middleware 可以定义其中任何一个或所有这些方法，这取决于你想要它提供什么样的功能。

当处理器内省 middleware 时，它查找上述名字的方法，并建立四个列表作为处理器的实例变量：

_request_middleware 是一个保存 process_request 方法的列表（在每一种情况下，它们是真正的方法，可以直接调用），这些方法来自于任一个定义了它们的 middleware 类。
_view_middleware 是一个保存 process_view 方法的列表，这些方法来自于任一个定义了它们的 middleware 类。
_response_middleware 是一个保存 process_response 方法的列表，这些方法来自于任一个定义了它们的 middleware 类。
_exception_middleware 是一个保存 process_exception 方法的列表，这些方法来自于任一个定义了它们的 middleware 类。

HttpRequest 准备好了就可以进入 Django

现在处理器已经准备好真正开始处理了，因此它给调度程序发送一个信号 request_started（Django 内部的调度程序允许各种不同的组件声明它们正在干什么，并可以写一些代码监听特定的事件。关于这一点目前还没有官方的文档，但在 wiki 上有一些注释。）。接下来它实例化一个 django.http.HttpRequest 的子类。

根据不同的处理器，可能是 django.core.handlers.modpython.ModPythonRequest 的一个实例，也可能是 django.core.handlers.wsgi.WSGIRequest 的一个实例。需要两个不同的类是因为 mod_python 和 WSGI APIs 以不同的格式传入 request 信息，这个信息需要解析为 Django 能够处理的一个单独的标准格式。

一旦一个 HttpRequest 或者类似的东西存在了，处理器就调用它自己的 get_response 方法，传入这个 HttpRequest 作为唯一的参数。这里就是几乎所有真正的活动发生的地方。