【转】请求处理机制其二:Django中间件的解析

Middleware 开始工作了

get_response 做的第一件事就是遍历处理器的 _request_middleware 实例变量并调用其中的每一个方法,传入 HttpRequest 的实例作为参数。

for middleware_method in self._request_middleware:
  response = middleware_method(request)
  if response:
    break

这些方法可以选择短路剩下的处理并立即让 get_response 返回,通过返回自身的一个值(如果它们这样做,返回值必须是 django.http.HttpResponse 的一个实例,后面会讨 论到)。如果其中之一这样做了,我们会立即回到主处理器代码,get_response 不会等着看其它 middleware 类想要做什么,它直接返回,然后处理器进入 response 阶段。

然而,更一般的情况是,这里应用的 middleware 方法简单地做一些处理并决定是否增加,删除或补充 request 的属性。

URL resolver 的解析

假设没有一个作用于 request 的 middleware 直接返回 response,处理器下一 步会尝试解析请求的 URL。它在配置文件中寻找一个叫做 ROOT_URLCONF 的配 置,用这个配置加上根 URL /,作为参数来创建 django.core.urlresolvers.RegexURLResolver 的一个实例,然后调用它的 resolve方法来解析请求的 URL 路径。

URL resolver 遵循一个相当简单的模式。对于在 URL 配置文件中根据 ROOT_URLCONF 的配置产生的每一个在 urlpatterns 列表中的条目,它会检查请 求的 URL 路径是否与这个条目的正则表达式相匹配,如果是的话,有两种选择:

  1. 如果这个条目有一个可以调用的 include,resolver 截取匹配的 URL,转到 include 指定的 URL 配置文件并开始遍历其中 urlpatterns 列表中的 每一个条目。根据你 URL 的深度和模块性,这可能重复好几次。
  2. 否则,resolver 返回三个条目:
    • 匹配的条目指定的 view function;
    • 一个 从 URL 得到的未命名匹配组(被用来作为 view 的位置参数);
    • 一个关键 字参数字典,它由从 URL 得到的任意命名匹配组和从 URLConf 中得到的任 意其它关键字参数组合而成。

注意这一过程会在匹配到第一个指定了 view 的条目时停止,因此最好让你的 URL 配置从复杂的正则过渡到简单的正则,这样能确保 resolver 不会首先匹配 到简单的那一个而返回错误的 view function。

如果没有找到匹配的条目,resolver 会产生 django.core.urlresolvers.Resolver404 异常,它是 django.http.Http404 例外的子类。后面我们会知道它是如何处理的。

# Apply view middleware
for middleware_method in self._view_middleware:
  response = middleware_method(request, callback, callback_args, callback_kwargs)
  if response:
    break

一旦知道了所需的 view function 和相关的参数,处理器就会查看它的 _view_middleware 列表,并调用其中的方法,传入 HttpRequst,view function,针对这个 view 的位置参数列表和关键字参数字典。

还有,Middleware 有可能介入这一阶段并强迫处理器立即返回。

上一篇:第二次C语言作业


下一篇:用eclipse运行和部署myeclipse项目