On Aug 16, 2010, at 11:56 AM, mdipierro wrote: > This is important and should be fixed. we will look into it. Perhaps > Jonathan who has worked on routes extensively can look into this.
I'm a little in the dark on routes_onerror; I recall looking at it a while back when I noticed that its doctest was failing, but I didn't figure it out. I looked at some of the logic now, though, and maybe there's a problem buried inside. 1. main.wsgibase populates request.env by lowercasing environ items (and replacing dots with underscores). 2. main.parse_url uses path_info in preference to request_uri. If path_info is missing, it parses request_uri into path_info and query_string. 3. If we're filtering routes_in, AND the rewritten path has a ? in it, we rewrite REQUEST_URI. But otherwise, we never do. I wonder if we shouldn't rewrite request_uri in filter_in regardless of whether there's a query string, and perhaps in parse_url, write something into request_uri if it's empty. The non-standardization of these variables is a PITA, from what I can tell. Another workaround might be for Rocket to go ahead and initialize request_uri, I suppose, but who knows what all the other web servers do? We could also try to rationalize the environment very early in an incoming request, perhaps just before filter_in. I hesitate to mess around in this logic, since it's so central to everybody's operation, and I have no idea what accidental "features" people might be depending on. Mike, on the basis of the above, and just as an experiment, you might try the same test but with a query string as part of your URL. If you're rewriting incoming URLs, that should cause request_uri to be initialized, and confirm what I've written above, or at least part of it. In that case, I think it'd be safe enough to write request_uri in the non-query-string case of filter_in. > > Massimo > > On Aug 16, 1:54 pm, mwolfe02 <[email protected]> wrote: >> Just tested this in my production environment (apache) and it works as >> expected. I'm having the problem in my dev environment which is >> running the built-in rocket server on windows. It looks like the >> Rocket server is not providing request_uri as apache with mod_wsgi >> does. >> >> If you just output the contents of request.env in the two different >> environments you will see the differences. According to the WSGI PEP >> (http://www.python.org/dev/peps/pep-0333/#environ-variables), >> request_uri is not a required environment variable. I don't think the >> 'requested_uri' functionality for routes_onerror is mentioned in the >> documentation anywhere, but if and when it is a caveat about its >> limitations with respect to different web servers should be mentioned. >> >> Unfortunately, I spent several hours trying to figure out what I was >> doing wrong before realizing it was not something I had any control >> over. I hope I can save someone else some trouble in the future. >> >> -Mike >> >> On Aug 16, 12:52 pm, mwolfe02 <[email protected]> wrote: >> >>> I'm trying to use routes_onerror, but requested_uri keeps coming >>> through as None (subject of this e-mail is the query string from the >>> redirect). I searched through the source code and could not find >>> where this is supposed to be set. I stepped through using WinPDB and >>> there is simply no entry in request.env for request_uri. There is an >>> entry for path_info which appears to be the re-written uri (ie, post >>> routes.py processing). >> >>> I'm running from trunk. Please let me know what other info is needed >>> to troubleshoot. >> >>> Thanks, >>> Mike
