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.

Reply via email to