quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Created: (MODPYTHON-146) ap_internal_fast_redirect() and request object cache
Date Mon, 13 Mar 2006 11:34:55 GMT
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


Mime
View raw message