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 h
andlers can add their own a
ttributes 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 req
uest as a whole before crea
ting 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 specif
ic 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_inte
rnal_fast_redirect() to determine if any of the files mentioned in the Direc
toryIndex directive exist.
What this function does is run through all request phases up to and includin
g 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 r
equest_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 con
sequence, the request object created for the sub request which worked and ra
n through to the fixup hand
ler phase is being ignored and that originally created for the parent reques
t continues to be used. As a consequence, any of the attributes added by han
dler 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 overl
ayed by the notes table con
tents 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 th
e request object created for the sub request, updating the request_rec membe
r to point to the parent re
quest_rec instead.

What may also come out of of storing an id for a request object in the req->notes table is t
hat when an internal redirect occurs, instead of a fresh request object wrapper instance bei
ng 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 attri
butes added into a request object of the parent request, something which can't curre
ntl
y 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 t
ry and attach some examples of handlers which demonstrate he problem.

Acknowledgements that you understand the issue appreciated.

[ Post a follow-up to this message ]