请求处理机制其二:Django中间件的解析
2013-08-14 00:00
281 查看
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 路径是否与这个条目的正则表达式相匹配,如果是的话,有两种选择:
如果这个条目有一个可以调用的 include,resolver 截取匹配的 URL,转到 include 指定的 URL 配置文件并开始遍历其中 urlpatterns 列表中的 每一个条目。根据你 URL 的深度和模块性,这可能重复好几次。
否则,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 有可能介入这一阶段并强迫处理器立即返回。
相关文章推荐
- [Django架构流程分析]请求处理机制其二:Django中间件的解析
- [Django架构流程分析]请求处理机制其三:view层与模板解析
- Django处理请求的工作机制
- [Django架构流程分析]请求处理机制其一:进入Django前的准备
- 请求处理机制其一:进入Django前的准备
- 请求处理机制其三:view层与模板解析
- django源码解析一(请求处理流程)
- Struts 2.3.24源码解析+Struts2拦截参数,处理请求,返回到前台过程详析
- flask基础之请求处理核心机制(五)
- Android 异步消息处理机制(Handler 、 Looper 、MessageQueue)源码解析
- Asp.Net请求处理机制中IsApiRuntime解析
- Android Handler 异步消息处理机制二:源码解析,深入理解Looper、Handler、Message三者关系
- Volley源码解析(三) 有缓存机制的情况走缓存请求的源码分析
- 解析Android消息处理机制:Handler/Thread/Looper & MessageQueue
- Tornado对Web请求与响应的处理机制
- 深入dwr2之三 Dwr2页面请求处理机制分析之engine.js
- ASP.NET Core应用针对静态文件请求的处理[3]: StaticFileMiddleware中间件如何处理针对文件请求
- DSS源码分析--对RTSP请求的状态机处理机制
- Android异步消息处理机制完全解析-Handler详解
- 高性能Web服务器Nginx的配置与部署研究(3)Nginx请求处理机制