Old description:
> The [http://wsgi.org/wsgi/Specifications/routing_args
> wsgiorg.routing_args] standard may be really useful if you want to use
> WSGI middleware or applications inside Django because some of them take
> advantage of that to do nice/useful things.
>
> It's currently not supported in Django - But it will with the attached
> patch.
New description:
The
[http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html
wsgiorg.routing_args] standard may be really useful if you want to use
WSGI middleware or applications inside Django because some of them take
advantage of that to do nice/useful things.
It's currently not supported in Django - But it will with the attached
patch.
''[edit] fixed broken link.''
--
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_docs: 0 => 1
Comment:
I've created a pull request for this:
https://github.com/django/django/pull/1004
I haven't written any documentation, but I'm happy to do it once it's been
approved, in case the solution changes radically.
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:8>
* owner: Gustavo Narea => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:9>
* owner: (none) => Anvesh Mishra
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:10>
Comment (by Anvesh Mishra):
Created a [https://github.com/django/django/pull/16269 PR], a lot
documentation still needs to be done and maybe some implementation
changes.
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:11>
* cc: Florian Apolloner (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:12>
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:13>
* needs_docs: 1 => 0
Comment:
Resetting docs flag for new PR
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:14>
Comment (by Florian Apolloner):
Two things that come to mind:
* On a technical level I think if this were to be in core it should be
done via `django/core/handlers/wsgi` where `resolve_request` could be
overwritten to set `request.environ/META` directly from the returned
`resolver_match` there (unconditionally, I don't see much gain in a
middleware and extra setters/getters for such a niche feature).
* On a organizational level I'd like to ask: Do we need this? If someone
wants it, there is always `request.resolver_match` which can be used to
copy this data into `environ['wsgiorg.routing_args']` as needed.
Given point two I'd like to ask if there are any popular python solutions
utilizing this, if yes then by all means let's include it. I could imagine
for instance that sentry's sdk (and others) could be using this to get
more information about the request (someone would need to check this) --
but aside from error reporting not much comes to mind that wouldn't be
easily worked around manually in code (ie when calling another wsgi app
from a django view etc…)
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:15>
* has_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:16>
Comment (by Anvesh Mishra):
Replying to [comment:15 Florian Apolloner]:
> Two things that come to mind:
>
> * On a technical level I think if this were to be in core it should be
done via `django/core/handlers/wsgi` where `resolve_request` could be
overwritten to set `request.environ/META` directly from the returned
`resolver_match` there (unconditionally, I don't see much gain in a
middleware and extra setters/getters for such a niche feature).
>
> * On a organizational level I'd like to ask: Do we need this? If
someone wants it, there is always `request.resolver_match` which can be
used to copy this data into `environ['wsgiorg.routing_args']` as needed.
>
> Given point two I'd like to ask if there are any popular python
solutions utilizing this, if yes then by all means let's include it. I
could imagine for instance that sentry's sdk (and others) could be using
this to get more information about the request (someone would need to
check this) -- but aside from error reporting not much comes to mind that
wouldn't be easily worked around manually in code (ie when calling another
wsgi app from a django view etc…)
Both points made seem fairly resonable so I would just like to ask what
would be the future of this ticket? maybe we can have a work around with
the `resolver_request` as stated in point 1.
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:17>
Comment (by Florian Apolloner):
The future depends on whether `routing_args` are used in the wild; if not
it will most likely be a wontfix.
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:18>
Comment (by Anvesh Mishra):
Replying to [comment:18 Florian Apolloner]:
> The future depends on whether `routing_args` are used in the wild; if
not it will most likely be a wontfix.
Got it
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:19>
* owner: Anvesh Mishra => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:20>
Comment (by Tom Carrick):
I ran a quick GitHub code search to see if anyone is using this with
Django:
https://github.com/search?q=%22routing_args%22+language%3APython+django&type=code
My conclusion is "not really".
And it can be done in middleware. So I'm not sure I see much reason to fix
this.
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:21>
* status: new => closed
* resolution: => wontfix
* stage: Accepted => Unreviewed
--
Ticket URL: <https://code.djangoproject.com/ticket/12075#comment:22>