Store single request object in scope

I’ve thought about doing so with regard to the templating, so that it does not have to be passed in via context, but https://github.com/encode/starlette/issues/495 looks like it would also help fixing state in this regard.

For templating it would be about saving the request there, and this could then be used instead of creating new objects then.

[blueyed]

@tomchristie Any feedback on my previous comment?

I’ve noticed this to be a problem again with request.state, where it would create new State objects for “new” Request objects (created via middleware and app for the same scope).

I am using a lazy property on State (via descriptor), and it would be good to have it only being created once really then. The workaround is to store/cache it on the request.state dict additionally.

[dmontagu]

Related – I think this design where the request gets recreated from the scope (in request_response, which may be called multiple times over the life of the request), but also holds some private cached state that is NOT carried over when the request is re-created (e.g., request._body) is the source of various confusion/surprising behavior, especially with middleware.

I could understand if the intention was to actively discourage conflicting designs (e.g., if they are viewed as anti-patterns), but I think 1) in at least some cases, legitimate approaches are running into issues, and 2) either way, it is currently relatively difficult to figure out the source of the problem, and requires digging into the framework internals.

---

Directionally, would there be support for a better API for transferring the cached state of the Request (e.g., request._is_stream_consumed, request._body, request._json, etc.) when creating a new Request?

I had a couple ideas about approaches to this:

1. Store any framework-internal request state in a separate object (perhaps similar to requests.State) that is stored on/read from the scope just like the current request.state, just using a different name (e.g., self.scope['_starlette_state']).

2. Approaches involving changes to the structure of scope['state']. (These should maybe be ignored outright if starlette should not be imposing any structure on scope['state']; I’m not sure if ASGI says anything specific about the use of that property of the scope.)

   1. Storing starlette-internal state in a low-chance-of-collision key (e.g., request.state.__starlette_state__ or similar) .

   2. Changing the internal structure of the dictionary stored in self.scope['state'] (or equivalently State._state) so that there are two top-level keys: internal and custom (or similar), each holding a dict. The current API (request.state.__getattr__, etc.) would then actually operate on the dict stored in self._state['custom'], and object.__getattr__(request.state, '_state')['internal'] could be used to access the internal state dict. (Admittedly the use of object.__getattr__ is a little awkward, but it would allow a change to the dict structure without a breaking API change.)

   3. The same modified structure of the dict stored in the request as described above, but adding a breaking API change to requests.State so that custom state is actually stored on an attribute State.custom, and framework internal state is stored on State.internal. (So request.state.custom would replace request.state.)

Thoughts?