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 有可能介入这一阶段并强迫处理器立即返回。