You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2005/12/18 06:47:34 UTC
[jira] Created: (MODPYTHON-100) raise apache.SERVER_RETURN, apache.OK aborts handlers.
raise apache.SERVER_RETURN, apache.OK aborts handlers.
------------------------------------------------------
Key: MODPYTHON-100
URL: http://issues.apache.org/jira/browse/MODPYTHON-100
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4, 3.2
Reporter: Graham Dumpleton
If multiple handlers are defined for a phase and a handler which isn't the last one, rather than returning the value apache.OK as the result, raises the apache.SERVER_RETURN exception with apache.OK as argument, then processing of subsequent handlers in that phase are being aborted.
Ie., consider the example with .htaccess file of:
SetHandler mod_python
PythonHandler example::handler_1
PythonHandler example::handler_2
and example.py of:
from mod_python import apache
def handler_1(req):
apache.log_error("handler_1")
req.content_type = 'text/plain'
req.write("HELLO")
# return apache.OK
raise apache.SERVER_RETURN, apache.OK
def handler_2(req):
apache.log_error("handler_2")
return apache.OK
The expectation would be that returning the value apache.OK from the handler function and raising an exception of type apache.SERVER_RETURN with argument apache.OK would be equivalent, but they aren't. When the exception is being raised, handler_2() function is never executed.
It would seem more sensible that they are equivalent as there are other specific status values that can be used in the case that one wants to prevent further handlers in the phase from being executed. For example, as appropriate, one of:
req.status = apache.HTTP_OK
raise apache.SERVER_RETURN, apache.DONE
or:
raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
or:
raise apache.SERVER_RETURN, apache.DECLINED
To fix this, the apache.SERVER_RETURN exception should be processed within the processing loop for each handler, rather than being handled outside of the loop. The status as returned by the exception should be translated to look like it was returned by the handler and dealt with as for other status values returned explicitly.
No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as already addresses this issue. :-)
--
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
[jira] Updated: (MODPYTHON-100) raise apache.SERVER_RETURN,
apache.OK aborts handlers.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-100?page=all ]
Graham Dumpleton updated MODPYTHON-100:
---------------------------------------
Assign To: Graham Dumpleton
> raise apache.SERVER_RETURN, apache.OK aborts handlers.
> ------------------------------------------------------
>
> Key: MODPYTHON-100
> URL: http://issues.apache.org/jira/browse/MODPYTHON-100
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.1.4, 3.2.7
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
>
> If multiple handlers are defined for a phase and a handler which isn't the last one, rather than returning the value apache.OK as the result, raises the apache.SERVER_RETURN exception with apache.OK as argument, then processing of subsequent handlers in that phase are being aborted.
> Ie., consider the example with .htaccess file of:
> SetHandler mod_python
> PythonHandler example::handler_1
> PythonHandler example::handler_2
> and example.py of:
> from mod_python import apache
> def handler_1(req):
> apache.log_error("handler_1")
> req.content_type = 'text/plain'
> req.write("HELLO")
> # return apache.OK
> raise apache.SERVER_RETURN, apache.OK
> def handler_2(req):
> apache.log_error("handler_2")
> return apache.OK
> The expectation would be that returning the value apache.OK from the handler function and raising an exception of type apache.SERVER_RETURN with argument apache.OK would be equivalent, but they aren't. When the exception is being raised, handler_2() function is never executed.
> It would seem more sensible that they are equivalent as there are other specific status values that can be used in the case that one wants to prevent further handlers in the phase from being executed. For example, as appropriate, one of:
> req.status = apache.HTTP_OK
> raise apache.SERVER_RETURN, apache.DONE
> or:
> raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
> or:
> raise apache.SERVER_RETURN, apache.DECLINED
> To fix this, the apache.SERVER_RETURN exception should be processed within the processing loop for each handler, rather than being handled outside of the loop. The status as returned by the exception should be translated to look like it was returned by the handler and dealt with as for other status values returned explicitly.
> No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as already addresses this issue. :-)
--
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
[jira] Work started: (MODPYTHON-100) raise apache.SERVER_RETURN,
apache.OK aborts handlers.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-100?page=all ]
Work on MODPYTHON-100 started by Graham Dumpleton
> raise apache.SERVER_RETURN, apache.OK aborts handlers.
> ------------------------------------------------------
>
> Key: MODPYTHON-100
> URL: http://issues.apache.org/jira/browse/MODPYTHON-100
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.1.4, 3.2.7
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
>
> If multiple handlers are defined for a phase and a handler which isn't the last one, rather than returning the value apache.OK as the result, raises the apache.SERVER_RETURN exception with apache.OK as argument, then processing of subsequent handlers in that phase are being aborted.
> Ie., consider the example with .htaccess file of:
> SetHandler mod_python
> PythonHandler example::handler_1
> PythonHandler example::handler_2
> and example.py of:
> from mod_python import apache
> def handler_1(req):
> apache.log_error("handler_1")
> req.content_type = 'text/plain'
> req.write("HELLO")
> # return apache.OK
> raise apache.SERVER_RETURN, apache.OK
> def handler_2(req):
> apache.log_error("handler_2")
> return apache.OK
> The expectation would be that returning the value apache.OK from the handler function and raising an exception of type apache.SERVER_RETURN with argument apache.OK would be equivalent, but they aren't. When the exception is being raised, handler_2() function is never executed.
> It would seem more sensible that they are equivalent as there are other specific status values that can be used in the case that one wants to prevent further handlers in the phase from being executed. For example, as appropriate, one of:
> req.status = apache.HTTP_OK
> raise apache.SERVER_RETURN, apache.DONE
> or:
> raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
> or:
> raise apache.SERVER_RETURN, apache.DECLINED
> To fix this, the apache.SERVER_RETURN exception should be processed within the processing loop for each handler, rather than being handled outside of the loop. The status as returned by the exception should be translated to look like it was returned by the handler and dealt with as for other status values returned explicitly.
> No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as already addresses this issue. :-)
--
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
[jira] Resolved: (MODPYTHON-100) raise apache.SERVER_RETURN,
apache.OK aborts handlers.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-100?page=all ]
Graham Dumpleton resolved MODPYTHON-100:
----------------------------------------
Fix Version: 3.3
Resolution: Fixed
Fix back ported into existing importer from new importer. Thus no longer dependent on new importer being used.
> raise apache.SERVER_RETURN, apache.OK aborts handlers.
> ------------------------------------------------------
>
> Key: MODPYTHON-100
> URL: http://issues.apache.org/jira/browse/MODPYTHON-100
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.7, 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
> Fix For: 3.3
>
> If multiple handlers are defined for a phase and a handler which isn't the last one, rather than returning the value apache.OK as the result, raises the apache.SERVER_RETURN exception with apache.OK as argument, then processing of subsequent handlers in that phase are being aborted.
> Ie., consider the example with .htaccess file of:
> SetHandler mod_python
> PythonHandler example::handler_1
> PythonHandler example::handler_2
> and example.py of:
> from mod_python import apache
> def handler_1(req):
> apache.log_error("handler_1")
> req.content_type = 'text/plain'
> req.write("HELLO")
> # return apache.OK
> raise apache.SERVER_RETURN, apache.OK
> def handler_2(req):
> apache.log_error("handler_2")
> return apache.OK
> The expectation would be that returning the value apache.OK from the handler function and raising an exception of type apache.SERVER_RETURN with argument apache.OK would be equivalent, but they aren't. When the exception is being raised, handler_2() function is never executed.
> It would seem more sensible that they are equivalent as there are other specific status values that can be used in the case that one wants to prevent further handlers in the phase from being executed. For example, as appropriate, one of:
> req.status = apache.HTTP_OK
> raise apache.SERVER_RETURN, apache.DONE
> or:
> raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
> or:
> raise apache.SERVER_RETURN, apache.DECLINED
> To fix this, the apache.SERVER_RETURN exception should be processed within the processing loop for each handler, rather than being handled outside of the loop. The status as returned by the exception should be translated to look like it was returned by the handler and dealt with as for other status values returned explicitly.
> No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as already addresses this issue. :-)
--
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
[jira] Closed: (MODPYTHON-100) raise apache.SERVER_RETURN,
apache.OK aborts handlers.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Graham Dumpleton closed MODPYTHON-100.
--------------------------------------
> raise apache.SERVER_RETURN, apache.OK aborts handlers.
> ------------------------------------------------------
>
> Key: MODPYTHON-100
> URL: https://issues.apache.org/jira/browse/MODPYTHON-100
> Project: mod_python
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.4, 3.2.7
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> If multiple handlers are defined for a phase and a handler which isn't the last one, rather than returning the value apache.OK as the result, raises the apache.SERVER_RETURN exception with apache.OK as argument, then processing of subsequent handlers in that phase are being aborted.
> Ie., consider the example with .htaccess file of:
> SetHandler mod_python
> PythonHandler example::handler_1
> PythonHandler example::handler_2
> and example.py of:
> from mod_python import apache
> def handler_1(req):
> apache.log_error("handler_1")
> req.content_type = 'text/plain'
> req.write("HELLO")
> # return apache.OK
> raise apache.SERVER_RETURN, apache.OK
> def handler_2(req):
> apache.log_error("handler_2")
> return apache.OK
> The expectation would be that returning the value apache.OK from the handler function and raising an exception of type apache.SERVER_RETURN with argument apache.OK would be equivalent, but they aren't. When the exception is being raised, handler_2() function is never executed.
> It would seem more sensible that they are equivalent as there are other specific status values that can be used in the case that one wants to prevent further handlers in the phase from being executed. For example, as appropriate, one of:
> req.status = apache.HTTP_OK
> raise apache.SERVER_RETURN, apache.DONE
> or:
> raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
> or:
> raise apache.SERVER_RETURN, apache.DECLINED
> To fix this, the apache.SERVER_RETURN exception should be processed within the processing loop for each handler, rather than being handled outside of the loop. The status as returned by the exception should be translated to look like it was returned by the handler and dealt with as for other status values returned explicitly.
> No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as already addresses this issue. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.