1. Django是如何处理请求的

我已决定开始为Django写一些软件架构方面的文章，描述核心的request处理机制是如何工作的。我要谈的Django的这一部分，是从浏览器得到一个request，把它转给一个response。我将不会讨论那些单独的组件：模板系统，O/R map，或者自动化的管理界面（admin interface）；实际上，构建一个Django应用你并不需要它们。

当Django收到一个request后，它做的第一件事是创建一个HttpRequest对象（原文此处有误，应为HttpResponse对象）（或者它的子类）去表示这个请求。如何用不同的代码去区别处理，依赖于host的环境，依赖于Django是运行于mod_python或者WSGI下面。这个HttpResponse对象是一个抽象类，能让Django工作于不同的主机环境下面。

一旦这个对象被创建，Django开始URL解析。这是个由request中的URL来决定由哪一个view functions去创建一个response的过程。一个最小的Django应用，简单到只有一个或者几个view functions，和一个用来把这些functions映射到URL上的配置文件。

当URL已经被解析到一个view上后，这个视图函数被调用，请求的对像将作为第一个参数。其它的几个关键参数也可能被传递，这依赖于URL的配置。细节请请参看URL相关的文档。视图函数（view function）作了大部分的工作：数据的查询，模板的load，HTML的生成，一个封装了结果的HttpResponse对象的创建等。这个视图函数返回一个对像，该对象传回到环境相关的代码,该代码将这个对象作为一个http应答传回到浏览器。

这是一个优美流畅的过程。但是我跳过了许多重要的细节：异常处理和中间件。视图函数不用返回一个HttpResponse，它可以用一个引发的异常来代替，比如常见的Http404（文件不存在）和Http500（服务器错误）。在开发服务器上，这些异常将被格式化并且回传到浏览器，在产品模式时，它们将被悄悄的记录在日志上，显示出来的则是友好的错误信息。

中间件比较有趣。Django提供三个hook，位于中间件类可以插入的次序上层，这些中间件类被定义在站点的配置文件里。有三种中间件类型：请求,视图和应答（尽管一个中间件类可以应用于多个hook上）。请求中间件，运行于HttpRequest对象创建之后，URL解析之前，它允许对请求作一定的修改，或者在余下的应用有机会运行之前返回一个它自己的应答。

视图中间件的运行时间，是在URL解析器被用来决定使用哪个视图之后，但在这个视图被运行之前。它被当作一个回调函数传递，让它在视图被执行之前和之后做一些操作。换句话说，它完全可以阻止视图的运行。应答中间件最后运行。在一个应答对象被创建之后，但在它被回传给客户端之前。它有能力对HttpResponse对象作最后的修改；举例来说，它可以从HTML中删除不必要的空格，或者进行gzip压缩。

上面说的这些东西的代码可以在ModPythonHandler类的call方法和BaseHandler类的get_response方法中找到。示例的中间件类可以在中间件的目录下面找到。由于Django还不是一个1.0 release版，上面的那些东西都可能会被修改。