[ 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
