Opened 15 years ago
Closed 14 months ago
#12075 closed New feature (wontfix)
Add wsgiorg.routing args support
Reported by: | Gustavo Narea | Owned by: | |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | WSGI, wsgiorg.routing_args |
Cc: | Florian Apolloner | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The 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.
Attachments (1)
Change History (23)
comment:1 by , 15 years ago
by , 15 years ago
Attachment: | django-wsgiorg-routing_args.diff added |
---|
Improved patch to support wsgiorg.routing_args
comment:2 by , 15 years ago
milestone: | 1.2 |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 15 years ago
Status: | new → assigned |
---|
I reimplemented this functionality as a Django middleware in twod.wsgi. That middleware has full unit test coverage:
http://bitbucket.org/2degrees/twod.wsgi/src/tip/twod/wsgi/middleware.py
http://bitbucket.org/2degrees/twod.wsgi/src/tip/tests/test_middleware.py
Would you like me to write a patch with the middleware or write tests for the initial patch?
comment:4 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:7 by , 12 years ago
Description: | modified (diff) |
---|
comment:8 by , 12 years ago
Needs documentation: | set |
---|
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.
comment:9 by , 4 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:10 by , 2 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:11 by , 2 years ago
Created a PR, a lot of documentation still needs to be done and maybe some implementation changes.
comment:12 by , 2 years ago
Cc: | added |
---|
comment:13 by , 2 years ago
Needs tests: | unset |
---|
follow-up: 17 comment:15 by , 2 years ago
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
whereresolve_request
could be overwritten to setrequest.environ/META
directly from the returnedresolver_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 intoenviron['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…)
comment:16 by , 2 years ago
Has patch: | unset |
---|
comment:17 by , 2 years ago
Replying to 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
whereresolve_request
could be overwritten to setrequest.environ/META
directly from the returnedresolver_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 intoenviron['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.
follow-up: 19 comment:18 by , 2 years ago
The future depends on whether routing_args
are used in the wild; if not it will most likely be a wontfix.
comment:19 by , 23 months ago
Replying to 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
comment:20 by , 16 months ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:21 by , 14 months ago
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.
comment:22 by , 14 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Triage Stage: | Accepted → Unreviewed |
I forgot to mention, the patch assumes that the WSGI environment is available, which won't true with mod_python until the patch I sent for #8927 is applied.