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
Assigned to: 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
