[jira] Work started: (MODPYTHON-152) req.main/prev from subrequest should yield true Python request object.

["Graham Dumpleton (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/MODPYTHON-152?page=all ]
     
Work on MODPYTHON-152 started by Graham Dumpleton

> req.main/prev from subrequest should yield true Python request object.
> ----------------------------------------------------------------------
>
>          Key: MODPYTHON-152
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-152
>      Project: mod_python
>         Type: Improvement

>   Components: core
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

>
> When a sub request is triggered using req.internal_redirect(), it is possible to access the details of the request_rec for the parent request by acessing req.main. Access will be via an instance of the Python request object wrapper, but rather than it referring to the actual Python request object wrapper instance that may have already been created for the parent request, a new instance is created. This means that a sub request cannot access attributes that may have been explicitly added to the Python request object wrapper in the main request.
> For example, in a parent request Python handler it may have gone:
>   req.session = Session.Session(req)
>   ...
>   req.internal_redirect(...)
> In the sub request, it is not currently possible to do something like:
>   req.session = req.prev.session
> where it is a reasonable expectation that trying to access parent request would allow added attributes to be seen.
> What would need to be done is for actions associated with accessing req.main, req.prev and req.next to use the get_request_object() function to get hold of request object so that if one already exists, it will be used and if not one will be created.
> Whether this could be done though would depend on what happens when a sub request is actually processed within the context of a distinct Python interpreter. Would there be issues with the Python request object wrapper being used from two distinct Python interpreters, especially where a multithreaded MPM were being used.
> If this isn't a problem, the next issue is how get_request_object() requires that the interpreter name and phase be supplied with the supplied values overriding those already in the request object.
> For interpreter name this would be a problem as accessing the main request object from a sub request in a different interpreter would change the value of interpreter seen by the parent request when it gets control back.
> The solution to this should perhaps be that the interpreter name should not even be stored in the request object wrapper to begin with. Instead, when req.interpreter is accessed, internally to mod_python it should map this to retrieving the value of apache.interpreter. This would eliminate the need for the interpreter name to even be supplied to get_request_object(), simplifying its calling interface.
> As to the phase attribute, all that is probably required is that when access req.main, req.next or req.prev it passes in phase as a NULL pointer. By doing this it wouldn't override any existing value if the request object already existed. If the request object didn't exist, then req.phase would return None. This latter situation would only exist where the internal redirect was performed by something other than mod_python.

-- 
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