You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -155,13 +159,14 @@ Multiple middlewares are applied in the order they are listed::
155
159
156
160
# Middlewares are applied in order: logging -> auth -> request
157
161
async with ClientSession(middlewares=(logging_middleware, auth_middleware)) as session:
158
-
resp = await session.get('http://example.com')
162
+
async with session.get("http://example.com") as resp:
163
+
...
159
164
160
-
A key aspect to understand about the flat middleware structure is that the execution flow follows this pattern:
165
+
A key aspect to understand about the middleware sequence is that the execution flow follows this pattern:
161
166
162
167
1. The first middleware in the list is called first and executes its code before calling the handler
163
-
2. The handler is the next middleware in the chain (or the actual request handler if there are no more middleware)
164
-
3. When the handler returns a response, execution continues in the first middleware after the handler call
168
+
2. The handler is the next middleware in the chain (or the request handler if there are no more middlewares)
169
+
3. When the handler returns a response, execution continues from the last middleware right after the handler call
165
170
4. This creates a nested "onion-like" pattern for execution
166
171
167
172
For example, with ``middlewares=(middleware1, middleware2)``, the execution order would be:
@@ -172,7 +177,12 @@ For example, with ``middlewares=(middleware1, middleware2)``, the execution orde
172
177
4. Exit ``middleware2`` (post-response code)
173
178
5. Exit ``middleware1`` (post-response code)
174
179
175
-
This flat structure means that middleware is applied on each retry attempt inside the client's retry loop, not just once before all retries. This allows middleware to modify requests freshly on each retry attempt.
180
+
This flat structure means that a middleware is applied on each retry attempt inside the client's retry loop,
181
+
not just once before all retries. This allows middleware to modify requests freshly on each retry attempt.
182
+
183
+
For example, if we had a retry middleware and a logging middleware, and we want every retried request to be
184
+
logged separately, then we'd need to specify ``middlewares=(retry_mw, logging_mw)``. If we reversed the order
185
+
to ``middlewares=(logging_mw, retry_mw)``, then we'd only log once regardless of how many retries are done.
176
186
177
187
.. note::
178
188
@@ -181,157 +191,6 @@ This flat structure means that middleware is applied on each retry attempt insid
181
191
like adding static headers, you can often use request parameters
182
192
(e.g., ``headers``) or session configuration instead.
183
193
184
-
Common Middleware Patterns
185
-
^^^^^^^^^^^^^^^^^^^^^^^^^^
186
-
187
-
.. _client-middleware-retry:
188
-
189
-
Authentication and Retry
190
-
""""""""""""""""""""""""
191
-
192
-
There are two recommended approaches for implementing retry logic:
193
-
194
-
1. **For Loop Pattern (Simple Cases)**
195
-
196
-
Use a bounded ``for`` loop when the number of retry attempts is known and fixed::
197
-
198
-
import hashlib
199
-
from aiohttp import ClientSession, ClientRequest, ClientResponse, ClientHandlerType
0 commit comments