From 75fb2fe8a364b05ed456ad7fa009e49c47670fb8 Mon Sep 17 00:00:00 2001 From: Chris Dent Date: Mon, 29 Jul 2019 17:26:52 +0100 Subject: [PATCH] Clarify the NOTE associated with ordering of middleware WSGI middleware is a confusing topic for people who are not familiar with it, so make the NOTE that describes how the ordering works more clear. Change-Id: I21680298f98f83d47e8319f01ad714cd96418c26 --- placement/deploy.py | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/placement/deploy.py b/placement/deploy.py index bc82de128..c0206744f 100644 --- a/placement/deploy.py +++ b/placement/deploy.py @@ -85,14 +85,24 @@ def deploy(conf): application, microversion.SERVICE_TYPE, microversion.VERSIONS, json_error_formatter=util.json_error_formatter) - # NOTE(cdent): The ordering here is important. The list is ordered - # from the inside out. For a single request request_log is called - # first and microversion_middleware last. Then the request is finally - # passed to the application (the PlacementHandler). At that point - # the response ascends the middleware in the reverse of the - # order the request went in. This order ensures that log messages + # NOTE(cdent): The ordering here is important. The list is ordered from the + # inside out. For a single request, request_log is called first (to extract + # request context information and log the start of the request). If + # osprofiler_middleware is present (see above), it is first. + # fault_middleware is last in the stack described below, to wrap unexpected + # exceptions in the placement application as valid HTTP 500 responses. Then + # the request is passed to the microversion middleware (configured above) + # and then finally to the application (the PlacementHandler, further + # above). At that point the response ascends the middleware in the reverse + # of the order the request went in. This order ensures that log messages # all see the same contextual information including request id and - # authentication information. + # authentication information. An individual piece of middleware is a + # wrapper around the next and can do work on the way in, the way out, or + # both. Which can be determined by looking at the `__call__` method in the + # middleware. "In" activity is done prior to calling the next layer in the + # stack (often `self.application`). "Out" activity is after, or in a + # redefinition of the `start_response` method, commonly called + # `replacement_start_response`. for middleware in (fault_middleware, context_middleware, auth_middleware,