On Aug 16, 2010, at 1:06 PM, Michael Wolfe wrote:
> I tried with the query string (?id=1) and I still got &requested_uri=None.
The logic is somewhat more convoluted than I though. request_uri only gets set
if routes_in actually adds a query string to the rewritten URL. This is
apparently because it sees a need to merge that query string with a possible
original query string.
>
> 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
>>
>>
>>
