Opened 15 years ago

Closed 7 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 Aymeric Augustin)

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)

django-wsgiorg-routing_args.diff (1.1 KB ) - added by Gustavo Narea 14 years ago.
Improved patch to support wsgiorg.routing_args

Download all attachments as: .zip

Change History (23)

comment:1 by Gustavo Narea, 15 years ago

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.

by Gustavo Narea, 14 years ago

Improved patch to support wsgiorg.routing_args

comment:2 by Russell Keith-Magee, 14 years ago

milestone: 1.2
Needs tests: set
Triage Stage: UnreviewedAccepted

comment:3 by Gustavo Narea, 14 years ago

Status: newassigned

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 Julien Phalip, 13 years ago

Severity: Normal
Type: New feature

comment:5 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:6 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:7 by Aymeric Augustin, 11 years ago

Description: modified (diff)

comment:8 by Gustavo Narea, 11 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 Mariusz Felisiak, 3 years ago

Owner: Gustavo Narea removed
Status: assignednew

comment:10 by Anvesh Mishra, 18 months ago

Owner: set to Anvesh Mishra
Status: newassigned

comment:11 by Anvesh Mishra, 18 months ago

Created a PR, a lot of documentation still needs to be done and maybe some implementation changes.

Last edited 18 months ago by Anvesh Mishra (previous) (diff)

comment:12 by Mariusz Felisiak, 18 months ago

Cc: Florian Apolloner added

comment:13 by Jacob Walls, 17 months ago

Needs tests: unset

comment:14 by Jacob Walls, 16 months ago

Needs documentation: unset

Resetting docs flag for new PR

comment:15 by Florian Apolloner, 16 months 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 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…)

comment:16 by Mariusz Felisiak, 16 months ago

Has patch: unset

in reply to:  15 comment:17 by Anvesh Mishra, 16 months 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 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.

comment:18 by Florian Apolloner, 16 months ago

The future depends on whether routing_args are used in the wild; if not it will most likely be a wontfix.

in reply to:  18 comment:19 by Anvesh Mishra, 16 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 Mariusz Felisiak, 9 months ago

Owner: Anvesh Mishra removed
Status: assignednew

comment:21 by Tom Carrick, 7 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 Mariusz Felisiak, 7 months ago

Resolution: wontfix
Status: newclosed
Triage Stage: AcceptedUnreviewed
Note: See TracTickets for help on using tickets.
Back to Top