[
https://issues.apache.org/jira/browse/MODPYTHON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-152.
--------------------------------------
> req.main/prev from subrequest should yield true Python request object.
> ----------------------------------------------------------------------
>
> Key: MODPYTHON-152
> URL: https://issues.apache.org/jira/browse/MODPYTHON-152
> Project: mod_python
> Issue Type: Improvement
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
