[ http://issues.apache.org/jira/brows...237
1703 ]

Graham Dumpleton commented on MODPYTHON-146:
--------------------------------------------

In addition to the sub request Python request object being ignored, the ap_i
nternal_fast_redirect() also doesn't transfer anything held in the sub reque
st req->request_config attribute. As well as holding the Python request obje
ct, this holds information
about dynamically registered handlers and input/output filters. Thus the spe
cifics of handlers and input/output filters registered by the sub request ar
e lost.


> 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 prima
ry 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 handler
s. This communication of information between handlers works because a handle
r will lookup to see if a request object has already been created for the re
quest as a whole before cr
eating a fresh request object wrapper, and will use the existing one instead.
> All in all this generally works okay, however, the DirectoryIndex directiv
e and the ap_internal_fast_redirect() do cause undesirable behaviour in spec
ific 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_redi
rect() to determine if any of the files mentioned in the DirectoryIndex directive ex
ist
. What this function does is run through all request phases up to and includ
ing the fixup handler phase for the file which would be matched for the entr
y in DirectoryIndex. If the status comes back OK indicating the request coul
d be satisfied, it copies a
ll the information from the sub request request_rec structure into the parent request_rec st
ructure. It will then proceed with this information to execute the content handler phase.[vb
col=seagreen]
> The problem is that ap_internal_fast_redirect() knows only about the request_rec s
tructure 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
 ha[/vbcol]
ndler 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 includin
g the fixup handler are lost.
> What possibly needs to be done is that the get_request_object() function in mod_py
thon needs to add to req->notes a tag which identifies the instance of the request o
bject which has been created. Because req->notes will be overlayed by the notes tabl
e c
ontents from the sub request, it will be able to detect when this copy of su
b 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 mem
ber 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 wr
apper instance being created to use for the req.main attribute, it can use the id in
 re
q->notes to actually get hold of the real request object of the parent and c
hain to it properly. Doing this will mean then that a sub request will be ab
le to access attributes added into a request object of the parent request, s
omething which can't curren
tly 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.

[ Post a follow-up to this message ]