Opened 16 years ago
Closed 2 years 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 , 16 years ago
by , 16 years ago
| Attachment: | django-wsgiorg-routing_args.diff added |
|---|
Improved patch to support wsgiorg.routing_args
comment:2 by , 16 years ago
| milestone: | 1.2 |
|---|---|
| Needs tests: | set |
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 16 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 , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:7 by , 13 years ago
| Description: | modified (diff) |
|---|
comment:8 by , 13 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 , 5 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:10 by , 3 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:11 by , 3 years ago
Created a PR, a lot of documentation still needs to be done and maybe some implementation changes.
comment:12 by , 3 years ago
| Cc: | added |
|---|
comment:13 by , 3 years ago
| Needs tests: | unset |
|---|
follow-up: 17 comment:15 by , 3 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/wsgiwhereresolve_requestcould be overwritten to setrequest.environ/METAdirectly from the returnedresolver_matchthere (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_matchwhich 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 , 3 years ago
| Has patch: | unset |
|---|
comment:17 by , 3 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/wsgiwhereresolve_requestcould be overwritten to setrequest.environ/METAdirectly from the returnedresolver_matchthere (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_matchwhich 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 , 3 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 , 3 years ago
Replying to Florian Apolloner:
The future depends on whether
routing_argsare used in the wild; if not it will most likely be a wontfix.
Got it
comment:20 by , 2 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:21 by , 2 years 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 , 2 years 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.