django源码阅读，WSGIHandler里middleware，view流程

WSGIHandler继承自BaseHandler，BaseHandler初始化的时候_request_middleware和其他moddleware变量都设置为None。 在WSGIHandler中，先通过判断_request_middleware为None，执行load_middleware。 在load_middleware里根据在settings.MIDDLEWARE_CLASSES里的配置导入所有middleware，并判断class里边包含的方法，分别插入相应的middleware列表里。现在_request_middleware是一个列表。load_middleware结束 回到WSGIHandler， set_script_prefix(base.get_script_name(environ))，get_script_name从environ得到SCRIPT_NAME，如果设置settings.FORCE_SCRIPT_NAME，回直接返回settings.FORCE_SCRIPT_NAME，默认为None。django竟然还提供这种碉堡的功能。。。set_script_prefix判断SCRIPT_NAME结尾是否是‘/’不是的话加上，并且在threading local里边保存SCRIPT_NAME。 signals.request_started.send(sender=self.__class__)，用来调用绑定到request_started的方法，大体看了一下没看懂。 request = self.request_class(environ)，得到request，初始化只是设置了一堆的变量。 response = self.get_response(request)，，在get_response里得到urlconf，settings.ROOT_URLCONF就是配置url的入口文件。这里先不看了，以后分析。接着在一个大的try语句里，设置response为None，遍历_request_middleware，只要有response返回就停止。如果执行完response还是none，下边匹配url找到view，然后遍历执行_view_middleware，有response就停止。然后遍历完response还是none执行view。 response = wrapped_callback(request, *callback_args, **callback_kwargs) 如果抛出异常，遍历执行_exception_middleware，返回response不为None就停止，如果最后为None，raise再抛异常。看出exception_middleware只用来在用户写的view里边出现异常的处理。 如果执行完view，还是none，就会抛出The view didn't return an HttpResponse object.的异常。 在这里前边的midddleware，只要有response返回，就不会执行后边的，直接到执行下边了。因为在执行middleware的前边，都先判断response是none才执行。 最后，判断response可调用render，遍历执行_template_response_middleware，最后调用response.render()。这个大的try语句检测执行上边这些操作的404 403等各种异常。 最后遍历执行_response_middleware里的方法，然后调用apply_response_fixes，执行response_fixes里的所有方法修改response。response_fixes在BaseHandler开始定义好了。处理完后返回response。 回到了WSGIHandler，设置http返回的headers，然后直接返回response。 WSGIHandler整个看完了，现在要详细看的好多了。 url的解析部分。 setting middleware里django的默认设置都做了什么。 wrapped_callback调view也看一下。（make_view_atomic这里是数据库事务相关内容） 还有没看懂的signal，以前也没接触过。