flask框架(下)
werkzeug简介
Werkzeug是一个WSGI工具包,他可以作为一个Web框架的底层库。这里稍微说一下, werkzeug 不是一个web服务器,也不是一个web框架,而是一个工具包,官方的介绍说是一个 WSGI 工具包,它可以作为一个 Web 框架的底层库,因为它封装好了很多 Web 框架的东西,例如 Request,Response 等等
通过 查看 flask.run() 源码可以发现,实际上执行的也是 werkzeug 下的 run_simlpe 函数
如下一个demo 可以看出 run_simple() 做了些什么
from werkzeug.serving import run_simple
from werkzeug.wrappers import Request, Response
@Request.application
def app(req):
print(req.method) # GET
print(req.path) # /
return Response('200 ok')
run_simple('0.0.0.0', 5000, app)
请求上下文
在django 中,每一个试图函数,都必需要接受一个request参数,才能执行试图函数,并且请求携带的参数也在request对象中,但是在flask 中,request 对象是一个全局对象,那么在多个请求过来时,flask是如何处理,才能在多线程条件下保证request对象携带参数是正确的?答案就在flask 的请求上下文管理中
flask 处理方案
入口还是在 app.run() 方法。
在 Flask 类中,可以发现重写的 __ call__ 方法。每当请求过来时,都会加括号执行app,因此都会自动执行__ call__方法。
继续往下,可以发现 wsgi_app 方法源码如下
继续往下,可以发现。request_context 实际上就是返回了 RequestContext 类的对象
回到 wsgi_app 方法中
push 源码
节约时间。下方直接 copy 参考博客截图。原文地址如下
_request_ctx_stack是LocalStack类的实例化对象:
LocalStack类中的__init__方法如下:
Local类的__init__方法如下:
get_ident是Local类所在文件中导入的一个方法名,该方法执行后会得到线程或协程ID,如下:
LocalStack类中的top是一个属性方法,源码如下:
下一步Local类中的__getattr__方法源码如下:
到此,分析得出top = _request_ctx_stack.top中的top为None。
接下来分析 **_request_ctx_stack.push(self)**做了什么?LocalStack类中的push方法源码如下:
Local类中的__setattr__方法源码如下:
因为rv.append(obj),所以最后LocalStack对象,即_request_ctx_stack对象字典化后如下:
{'_local':{'__storage__':{9527:{stack:[ctx]}}, '__ident_func__':get_ident}}
# 说明:9527假设是获取到的线程或者协程号,ctx包含request对象和session对象。
到此,flask请求上文结束,也就是完成了将一个request和session对象存储到某个地方。
总结
1. 请求来时,flask 会把当次请求对象 request 放到 local 对象中,每个请求都是一个线程
local对象实际管理的就是一个字典,里面以线程或者协程id为key,请求对象为value 值
2. 使用时,会根据 key 到 local 对象中取值,确保携带的值不会出错
3. 请求结束,flask 会把 该次 request 对象从local中移除
4. g 对象和 session 也是采用上述相同处理。
补充
在阅读过程中发现,request对象,session和g对象都是同一个类 LocalProxy的对象,
LocalProxy类是个代理类, 重写了所有的魔法方法。来我们在使用时,request,session,g对象的属性打印出来的属性不一致。