[ http://issues.apache.org/jira/browse/MODPYTHON-146?page=comments#action_12372756 ]
Graham Dumpleton commented on MODPYTHON-146: -------------------------------------------- A more through analysis of the DirectoryIndex problems was posted on the mod_python developers mailing list: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01736.html > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
