#8927: Make Request proxy the WSGI environ
-------------------------------+------------------------------------
Reporter: simon | Owner: nobody
Type: New feature | Status: reopened
Component: HTTP handling | Version: SVN
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by carljm):
Replying to [comment:16 Gustavo]:
> "Proxy" means that if, for example, you set "request.path = '/foo'", the
change will propagate to "request.environ['PATH_INFO']".
I see. There does not appear to be a consensus within the WSGI community
(even outside Django) that this is a good idea. WebOb does this, Werkzeug
does not. I just discussed it on IRC with mitsuhiko, and there are some
real issues with implementing this. Like - what all do you attempt to
proxy? Even in "simple" cases like the path, you have to deal with
encoding back and forth, since request.path is unicode and
`request.environ['PATH_INFO']` is a string. What about the request body
(form data)? To proxy this back, you're kind of fighting against WSGI - it
sounds like WebOb dumps it into a temporary file, which is complicated and
possibly slow.
I understand that if you have a mutable request object, not proxying
changes back to the WSGI environ can cause inconsistencies if you later
dispatch internally to another WSGI app. Werkzeug deals with this by
documenting the request object as immutable (though in fact it isn't
entirely). We do already have people in Django modifying request.path in
middleware (e.g. django-localeurl does this to make the locale URL prefix
transparent to the app), so it's a bit late for us to take the "request is
immutable" approach.
Personally, I'm not convinced this is necessary for good WSGI support. I
think we could just document that changes to the request are not reflected
in the WSGI environ, and people in the (unusual) situation of both
modifying the request object and dispatching to another WSGI app can deal
with it for their specific situation.
Another option, if the only real use case for this is when you dispatch to
another WSGI app, would be to implement some of this in the
`call_wsgi_app` wrapper or whatever implements #12091. In other words,
changes to the request would not immediately be reflected in
request.environ, but `call_wsgi_app` would attempt to notice some cases
(like request.path modification) and reflect those changes in the WSGI
environ it passes on to the called app. This would feel less invasive to
me, and seems like it would meet the use case adequately.
--
Ticket URL: <https://code.djangoproject.com/ticket/8927#comment:18>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
