Graham Dumpleton commented on MODPYTHON-146:

A more through analysis of the DirectoryIndex problems was posted on the 
mod_python developers mailing list:


> ap_internal_fast_redirect() and request object cache
> ----------------------------------------------------
>          Key: MODPYTHON-146
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-146
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.2.8
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

> mod_python uses a Python class to wrap the Apache request_rec structure. The 
> primary purpose of the request object wrapper is to access the request_rec 
> internals. One of the other features of the request object wrapper is that 
> handlers can add their own attributes to it, to facilitate communication of 
> information between handlers. This communication of information between 
> handlers works because a handler will lookup to see if a request object has 
> already been created for the request as a whole before creating a fresh 
> request object wrapper, and will use the existing one instead.
> All in all this generally works okay, however, the DirectoryIndex directive 
> and the ap_internal_fast_redirect() do cause undesirable behaviour in 
> specific cases.
> Now when a request is made against a directory, this is detected by mod_dir, 
> which in a LAST hooked handler in the fixup handler phase, will use 
> ap_internal_fast_redirect() to determine if any of the files mentioned in the 
> DirectoryIndex directive exist. What this function does is run through all 
> request phases up to and including the fixup handler phase for the file which 
> would be matched for the entry in DirectoryIndex. If the status comes back OK 
> indicating the request could be satisfied, it copies all the information from 
> the sub request request_rec structure into the parent request_rec structure. 
> It will then proceed with this information to execute the content handler 
> phase.
> The problem is that ap_internal_fast_redirect() knows only about the 
> request_rec structure and nothing about the Python request object wrapper. As 
> a consequence, the request object created for the sub request which worked 
> and ran through to the fixup handler phase is being ignored and that 
> originally created for the parent request continues to be used. As a 
> consequence, any of the attributes added by handler phases up to and 
> including the fixup handler are lost.
> What possibly needs to be done is that the get_request_object() function in 
> mod_python needs to add to req->notes a tag which identifies the instance of 
> the request object which has been created. Because req->notes will be 
> overlayed by the notes table contents from the sub request, it will be able 
> to detect when this copy of sub request data into the parent has occured. It 
> can then decide to switch to the request object created for the sub request, 
> updating the request_rec member to point to the parent request_rec instead.
> What may also come out of of storing an id for a request object in the 
> req->notes table is that when an internal redirect occurs, instead of a fresh 
> request object wrapper instance being created to use for the req.main 
> attribute, it can use the id in req->notes to actually get hold of the real 
> request object of the parent and chain to it properly. Doing this will mean 
> then that a sub request will be able to access attributes added into a 
> request object of the parent request, something which can't currently be done.
> Now, if you understand everything I have said above, you have done well. ;-)
> Depending on whether people do understand or not, when I get a chance I'll 
> try and attach some examples of handlers which demonstrate he problem.
> Acknowledgements that you understand the issue appreciated.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

Reply via email to