django从请求到响应的过程深入讲解

django启动

我们在启动一个django项目的时候，无论你是在命令行执行还是在pycharm直接点击运行，其实都是执行runserver的操作，而ruserver是使用django自带的的web server，主要用于开发和调试中，而在正式的环境中，一般会使用nginx+uwsgi模式。

无论是哪种方式，当启动一个项目，都会做2件事：

创建一个WSGIServer类的实例，接受用户的请求。 当一个用户的http请求到达的时，为用户指定一个WSGIHandler，用于处理用户请求与响应，这个Handler是处理整个request的核心。

WSGI

WSGI：全称是Web Server Gateway Interface，WSGI不是服务器，也不用于与程序交互的API，更不是代码，而只是定义了一个接口，用于描述web server如何与web application通信的规范。
当客户端发送一次请求后，最先处理请求的实际上是 web 服务器就是我们经常说的 nginx、Apache 这类的 web 服务器，然后web服务器再把请求交给web应用程序(如django)处理，这中间的中介就是WSGI，它把 web 服务器和 web 框架 (Django) 连接起来。

简单介绍一下WSGI的一些内容，它规定应用是可调用对象(函数/方法)，然后它接受2个固定参数：一个是含有服务器端的环境变量，另一个是可调用对象，这个对象用来初始化响应，给响应加上status code状态码和httpt头部，并且返回一个可调用对象。可以看个简单的例子

# 这段代码来自python核心编程 def simplr_wsgi_app(environ, start_response): # 固定两个参数，django中也使用同样的变量名 status = 200 OK headers = [{Content-type: text/plain}] # 初始化响应, 必须在返回前调用 start_response(status, headers) # 返回可迭代对象 return [hello world!]

django中，实现同样逻辑的是通过WSGIHandler这个类，下面我们也会重点介绍它！

如果对WSGI与uWSGI有兴趣的，推荐大家看这篇文章，WSGI & uwsgi ，大赞！

中间件基本概念

顾名思义，中间件是位于Web服务器端和Web应用之间的，它可以添加额外的功能。当我们创建一个django项目(通过pycharm)，它会自动帮我们设置一些必要的中间件。

中间件要么对来自用户的数据进行预处理，然后发送给应用；要么在应用将响应负载返回给用户之前，对结果数据进行一些最终的调整。通俗一点，在django中，中间能够帮我们准备好request这个对象，然后应用可以直接使用request对象获取到各类数据，也帮我们将response添加头部，状态码等。

数据流

当django接受到一个请求时，会初始化一个WSGIHandler，可以在项目下的wsgi.py文件进行跟踪，你就会发现这一个类。

class WSGIHandler(base.BaseHandler): def __call__(self, environ, start_response): pass

这个类遵循WSGI应用的规定，它接受2个参数：一个是含有服务器端的环境变量，另一个是可调用对象，返回一个可迭代对象。

这个handler控制了从请求到响应的整个过程，主要流程：

在网上看到另外一张图，更为完整：

大致几个步骤：

1. 用户通过浏览器请求一个页面

2. 请求到达Request Middlewares，中间件对request做一些预处理或者直接response请求

3. URLConf通过urls.py文件和请求的URL找到相应的View

4. View Middlewares被访问，它同样可以对request做一些处理或者直接返回response

5. 调用View中的函数

6. View中的方法可以选择性的通过Models访问底层的数据

7. 所有的Model-to-DB的交互都是通过manager完成的

8. 如果需要，Views可以使用一个特殊的Context

9. Context被传给Template用来生成页面

a.Template使用Filters和Tags去渲染输出

b.输出被返回到View

c.HTTPResponse被发送到Response Middlewares

d.任何Response Middlewares都可以丰富response或者返回一个完全不同的response

e.Response返回到浏览器，呈现给用户

中间类中的顺序与方法

django 的中间件类至少含有以下四个方法中的一个：
process_request、 process_view、process_exception、process_response
WSGIHandler通过load_middleware将这个些方法分别添加到_request_middleware、_view_middleware、_response_middleware 和 _exception_middleware四个列表中。

并不是每个中间件都有这4个方法，如果不存在某个方法，那么在加载的过程中，这个类就被跳过。

for middleware_path in settings.MIDDLEWARE_CLASSES: ···ert(0, mw_instance.process_template_response) if hasattr(mw_instance, process_response): self._response_middleware.insert(0, mw_instance.process_response) if hasattr(mw_instance, process_exception): self._exception_middleware.insert(0, mw_instance.process_exception)

我们可以从源码看出，process request 和 process response的执行加载顺序正好是相反，在循环中，process_request是被append到列表的末尾，而process_request是被insert到最前面的。

（可能有些情况Comment中间件在Session前面，了解加载的顺序就好了）

process_request

举几个中间件的例子

class CommonMiddleware(object): # 伪代码A: for user_agent_regex in settings.DISALLOWED_USER_AGENTS: if user_agent_regex.search(request.META[HTTP_USER_AGENT]): raise PermissionDenied(Forbidden user agent) host = request.get_host() if settings.PREPEND_

CommonMiddleware的process_request主要是判断用户代理是否符合要求以及在完善URL，如增加www或者末尾加/。

SessionMiddleware的process_request是把session_key从cookies中取出来然后放到request.session中。

在前面提过，中间件的加载是按照一定顺序（正反序），
AuthenticationMiddleware的process_request方法基于session中间件被加载过了，然后通过request的session，将用户取出来放入到request.user 。

process_request 应该返回 None 或者 HTTPResponse 对象。当返回 None 时，WSGI handler 会继续加载 process_request 里面的方法，如果是后一种情况，那么Handlers会直接加载_response_middleware的列表，然后直接response。

解析 url

当_request_middleware列表中的 process_request 被遍历完，会得到一个经过处理的request对象（加入了request.session,request.user等属性）。

django将按顺序进行对url进行正则匹配，如果匹配不成功，就会抛出异常。如果request的中间件返回None，那么Django会去解析用户请求的URL。

在setting中有一个ROOT_URLCONF，它指向urls.py文件，根据这个文件可以生产一个urlconf，本质上，他就是url与视图函数之间的映射表，然后通过resolver解析用户的url，找到第一个匹配的view。

process_view

经过url的匹配，会获得视图函数以及相关参数。在调用view函数之前，django会先加载_view_middleware中的各个process_view方法。

逐个默认的中间件看了一遍，只看到csrf有这个方法

# 伪代码 class CsrfViewMiddleware(object): def process_view(self, request, callback, callback_args, callback_kwargs): if getattr(request, csrf_processing_done, False): return None try: csrf_token = _sanitize_token( request.COOKIES[settings.CSRF_COOKIE_NAME]) # Use same token next time request.META[CSRF_COOKIE] = csrf_token except KeyError: csrf_token = None if getattr(callback, csrf_exempt, False): return None pass

这个方法的作用是判断cookiers中是否存在csrf的字段，如果不存在，会直接抛出异常，如果存在，返回None。
view中间件和requst中间件一样，必须返回None或一个httpResponse,如果返回一个httpresponse，那么Handlers会直接加载_response_middleware的列表，然后返回HttpResponse，那么Handlers会直接加载_response_middleware的列表，然后直接response

执行view逻辑

view函数需要满足：

基于函数（FBV）或者基于类的（CVB）的视图。 接受的参数第一个必须为request，并且需要返回一个response对象。

如果视图函数抛出一个异常，Handler 将会循环遍历_exception_middleware 列表，如果有一个异常被抛出，后面的 process_exception 将不会被执行。

process_response

在这个阶段，我们得到了一个 HTTPResponse 对象，这个对象可能是 process_view 返回的，也可能是视图函数返回的。现在我们将循环访问响应中间件。这是中间件调整数据的最后的机会。举个例子：

class XFrameOptionsMiddleware(object): def process_response(self, request, response): # Dont set it if its already in the response if response.get(X-Frame-Options) is not None: return response # Dont set it if they used @xframe_options_exempt if getattr(response, xframe_options_exempt, False): return response response[X-Frame-Options] = self.get_xframe_options_value(request, response) return response

XFrameOptionsMiddleware将X-Frame-Options加入到response当中，防止网站被嵌套、被劫持。

class CsrfViewMiddleware(object): def process_response(self, request, response): if getattr(response, csrf_processing_done, False): return response if not request.META.get(CSRF_COOKIE_USED, False): return response # Set the CSRF cookie even if its already set, so we renew # the expiry timer. response.set_cookie(settings.CSRF_COOKIE_NAME, request.META[CSRF_COOKIE], max_age=settings.CSRF_COOKIE_AGE, domain=settings.CSRF_COOKIE_DOMAIN, path=settings.CSRF_COOKIE_PATH, secure=settings.CSRF_COOKIE_SECURE, httponly=settings.CSRF_COOKIE_HTTPONLY ) # Content varies with the CSRF cookie, so set the Vary header. patch_vary_headers(response, (Cookie,)) response.csrf_processing_done = True return response

CsrfViewMiddleware在response中设置csrf cookies

最后

当response的中间件加载完，系统在返回之前会调用WSGI服务器端传过来的start_response方法对象，初始化响应，然后进行response响应。

总结

本文重点在于：

django启动时，启动了一个WSGIserver以及为每个请求的用户生成一个handler。 理解WSGI协议，并且WSGIHandler这个类控制整个请求到响应的流程，以及整个流程的基本过程。 中间件的概念，以及每一个process_request, process_response, process_view, process_exception方法在哪个步骤发挥着什么样的作用。 中间价的执行时有顺序的，request与view是按照顺序去执行的，而response和exception是反序的，这一步实在WSGIHandler在加载到它的各个列表的时候完成的。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。

参考博客：

  1，Django教程笔记：六、中间件middleware
  2，做python Web开发你要理解：WSGI & uwsgi
  3，从请求到响应 django 都做了哪些处理  
  4，django从请求到返回都经历了什么