墟沟企业建站价格表,苏州做网站的公司排名,详情页设计思路,云企网站文章目录flask框架(下)werkzeug简介请求上下文flask 处理方案回到 wsgi_app 方法中push 源码总结补充flask框架(下)
werkzeug简介
Werkzeug是一个WSGI工具包#xff0c;他可以作为一个Web框架的底层库。这里稍微说一下#xff0c; werkzeug 不是一个web服务器#xff0c;也…
文章目录flask框架(下)werkzeug简介请求上下文flask 处理方案回到 wsgi_app 方法中push 源码总结补充flask框架(下)
werkzeug简介
Werkzeug是一个WSGI工具包他可以作为一个Web框架的底层库。这里稍微说一下 werkzeug 不是一个web服务器也不是一个web框架而是一个工具包官方的介绍说是一个 WSGI 工具包它可以作为一个 Web 框架的底层库因为它封装好了很多 Web 框架的东西例如 RequestResponse 等等
通过 查看 flask.run() 源码可以发现实际上执行的也是 werkzeug 下的 run_simlpe 函数 如下一个demo 可以看出 run_simple() 做了些什么
from werkzeug.serving import run_simple
from werkzeug.wrappers import Request, ResponseRequest.application
def app(req):print(req.method) # GETprint(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类是个代理类 重写了所有的魔法方法。来我们在使用时requestsessiong对象的属性打印出来的属性不一致。
