I tried with the query string (?id=1) and I still got &requested_uri=None.
In case I'm doing something non-standard that's contributing to the
problem, here is my routes.py file (with comments and doctests
removed):
routes_in = (
('/admin/$anything', '/admin/$anything'),
('/static/$anything', '/paytaxes/static/$anything'),
('/appadmin/$anything', '/paytaxes/appadmin/$anything'),
('/favicon.ico', '/paytaxes/static/favicon.ico'),
('/robots.txt', '/paytaxes/static/robots.txt'),
('/', '/paytaxes/default/search'),
('/$anything', '/paytaxes/default/$anything'),
)
routes_out = [(x, y) for (y, x) in routes_in[:-3]]
routes_out.append(('/paytaxes/default/$anything', '/$anything'))
routes_onerror = [
('*/400','/error'),
('*/*', '/error'),
]
On Mon, Aug 16, 2010 at 3:52 PM, Jonathan Lundell <[email protected]> wrote:
> 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
>
>
>
