Context Navigation

Changes between Initial Version and Version 1 of Ticket #37025, comment 5

initial	v1
3	3	The WSGI implementation is based on the idea that in the normal case the `request.META` entry is not in fact an HTTP header, but an environment variable. In contrast in the ASGI case, the value must come from a header value, as there's no other way. Thus the difference in implementation.
4	4
5		I'm pretty sceptical that people are needing both WSGI and ASGI versions of the middleware with the same custom header value. Possibly would could add an `resolve_meta_key` helper, called on the `aprocess_request` path that formatted the header, maybe via a class attribute, which could then be overridden to unify the approach if a fully qualified header was provided. 🤷
	5	I'm pretty sceptical that people are needing both WSGI and ASGI versions of the middleware with the same custom header value. Possibly would could add an `resolve_meta_key` helper, called on the `aprocess_request` path that formatted the header, maybe via a class attribute, which could then be overridden to unify the approach if a fully qualified header was provided. 🤷 (Edit: moving the `HTTP_` to a `header_prefix` class attribute might even be enough here: if set to `""` it would allow `self.header` to be the fully qualified version.)
6	6