请求情境

请求情境在请求期间跟踪请求级数据。不是将请求对象传递给在请求期间运行的每个函数，而是访问 request 和 session 代理。

这类似于 应用情境 ，它跟踪独立于请求的应用程序级数据。当请求上下文被推送时，对应的应用上下文被推送。

情境的用途

当 Flask 应用处理请求时，它会根据从 WSGI 服务器收到的环境创建一个 Request 对象。因为工作者 （取决于服务器的线程，进程或协程）一 次只能处理一个请求，所以在该请求期间请求数据可被认为是该工作者的全局数据。 Flask 对此使用术语本地情境 。

处理请求时，Flask 自动推送请求情境。在请求期间运行的视图函数，错误处理器和其他函数将有权访问 request 代理，该请求代理指向当前请求的请 求对象。

情境的生命周期

当FlaskTM应用程序开始处理请求时，它会推送请求上下文，这也会推送 app context 。当请求结束时，它弹出请求上下文，然后弹出应用程序上下文。

上下文对于每个线程(或其他工作线程类型)是唯一的。 request 无法传递给另一个线程，另一个线程具有不同的上下文空间，并且不知道父线程所指向的请求。

上下文局部变量是使用Python的 contextvars 和Werkzeug的 LocalProxy 。Python自动管理上下文变量的生存期，本地代理包装该低级接口以使数据更易于使用。

手动推送情境

如果尝试在请求情境之外访问 request 或任何使用它的东西，那么会收到这个错误消息：

RuntimeError: Working outside of request context.

This typically means that you attempted to use functionality that
needed an active HTTP request. Consult the documentation on testing
for information about how to avoid this problem.

通常只有在测试代码期望活动请求时才会发生这种情况。一种选择是使用测试客户端来模拟完整的请求。或者，可以在 with 块中使用 test_request_context() ，块中运行的所有内容 都可以访问请求，并填充测试数据。:

def generate_report(year):
    format = request.args.get("format")
    ...

with app.test_request_context(
    "/make_report/2017", query_string={"format": "short"}
):
    generate_report()

如果在代码中的其他地方看到与测试无关的错误，则很可能表明应该将该代码移到视图函数中。

有关如何使用来自交互python shell的请求情境的信息，请参见 在Shell中使用Flask .

情境如何工作

这个 Flask.wsgi_app() 方法来处理每个请求。它在请求期间管理上下文。在内部，请求和应用程序上下文就像堆栈一样工作。当上下文被推送时，依赖于它们的代理可用，并指向来自顶端项目的信息。

当请求开始时，将创建并推送 RequestContext ，如果该应用程序的情境尚不是顶级情境，则该请求会首先创建并推送 AppContext 。在 推送这些情境时，current_app 、 g 、 request 和 session 代理可用于处理请求的原始线程。

可以在请求期间推送其他上下文来改变代理。虽然这不是一种常见的模式，但它可以在高级应用程序中使用，例如，执行内部重定向或将不同的应用程序链接在一起。

在发送请求并生成和发送响应之后，将弹出请求上下文，然后弹出应用程序上下文。在它们被弹出之前， teardown_request() 和 teardown_appcontext() 执行函数。即使在调度过程中发生未处理的异常，也会执行这些操作。

回调和错误

Flask 会在多个阶段调度请求，这会影响请求，响应以及如何处理错误。情境在所有 这些阶段都处于活动状态。

Blueprint 可以为这些特定于蓝图的事件添加处理程序。如果蓝图拥有与请求匹配的路由，则蓝图的处理程序将运行。

  1. 在每次请求之前，before_request() 函数都会被调用。如果其中一个函数返回了一个值，则其他函数将被跳过。返回值被视为响应，并且视图函数不会被调用。

  2. 如果`before_request` 函数没有返回响应，将调用匹配路由的视图函数并返回响应。

  3. 视图的返回值将转换为实际响应对象并传递给 after_request 函数。每个函数都返回一个已修改或新的响应对象。

  4. 返回响应后，将弹出情境，该情境调用 teardown_request() 和 teardown_appcontext() 函数。即使在上面任何一处引发了未处理的异常，也会调用这些函数。

如果在拆卸函数之前引发异常，则Flask将尝试将其与 errorhandler 函数进行匹配来处理异常并返回响应。如果找不到错误处理程序，或者处理程序本身引发异常，则flask返回一个通用的 500 Internal Server Error 反应。TearDown函数仍然被调用，并被传递给异常对象。

如果启用了调试模式，则未处理的异常不会转换为 500 响应，而是会传播到 WSGI 服务器。这允许开发服务器向交互式调试器提供回溯。

拆卸回调

拆除回调与请求派发无关，而在情境弹出时由情境调用。即使在调度过程中出现未处 理的异常，以及手动推送的情境，也会调用这些函数。这意味着不能保证请求调度的 任何其他部分都先运行。 一定要以不依赖其他回调的方式编写这些函数，并且不会 失败。

在测试期间，延迟在请求结束后弹出上下文是很有用的，这样就可以在测试函数中访问上下文的数据。使用 test_client() 作为一个 with 块以保留上下文，直到 with 封锁出口。

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def hello():
    print('during view')
    return 'Hello, World!'

@app.teardown_request
def show_teardown(exception):
    print('after with block')

with app.test_request_context():
    print('during with block')

# teardown functions are called after the context with block exits

with app.test_client() as client:
    client.get('/')
    # the contexts are not popped even though the request ended
    print(request.path)

# the contexts are popped and teardown functions are called after
# the client with block exits

信号

发送以下信号：

  1. request_started 发送于 before_request() 函数被调用之前。

  2. request_finished 发送于 after_request() 函数被调用之后。

  3. got_request_exception 发送于异常开始处理的时候 但早于 an errorhandler() 被找到或者调用的时候。

  4. request_tearing_down 发送于 teardown_request() 函数被调用之后。

代理须知

Flask 提供的一些对象是其他对象的代理。每个工作线程都能以相同的方式访问代理，但是在后台每个工作线程绑定了唯一对象。如本页所述。

大多数情况下，您不必关心这个问题，但也有一些例外情况，知道这个对象实际上是一个代理是很好的：

  • 代理对象不能将其类型伪装为实际的对象类型。如果要执行实例检查，则必须在被代理的对象上执行该操作。

  • 在某些情况下需要对代理对象的引用，例如发送 信号 或者将数据传递到后台线程。

如果您需要访问被代理的源对象，请使用 _get_current_object() 方法:

app = current_app._get_current_object()
my_signal.send(app)