| Graham Dumpleton (JIRA) 2006-02-13, 2:47 am |
| [ http://issues.apache.org/jira/brows...ON-129?page=all ]
Graham Dumpleton updated MODPYTHON-129:
---------------------------------------
Description:
Todays daily bug report, or is it? ;-)
The Python*Handler documentation says:
"""Multiple handlers can be specified on a single line, in which case they will be called sequentially, from left to right. Same handler directives can be specified multiple times as well, with the same result - all handlers listed will be executed sequen
tially, from first to last. If any handler in the sequence returns a value other than apache.OK, then execution of all subsequent handlers is aborted."""
That is, no matter which phase is being processed, mod_python will stop processing them if a value other than OK is returned.
Problem is that this isn't how Apache itself treats the result from handlers. Apache actually implements two different ways for dealing with the result from the handlers. Which is used depends on which processing phase is occuring. This is all specified b
y the Apache magic macro code:
AP_IMPLEMENT_HOOK_RUN_FIRST(int,translat
e_name,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,map_to_s
torage,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,check_us
er_id,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,auth_che
cker,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int,access_che
cker,
(request_rec *r), (r), OK, DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,type_che
cker,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int,fixups,
(request_rec *r), (r), OK, DECLINED)
What this gobblegook expands to are loops which will stop processing handlers based on the result.
For the AP_IMPLEMENT_HOOK_RUN_ALL macro, all handlers in the phase will be run unless one returns something other than OK or DECLINED. Returning OK means that it did something and it worked okay. Returing DECLINED means that it didn't do anything at all.
In both these cases, it still goes onto the next handler in that phase. After that it will go onto the next phase.
Returning an error will cause appropriate error response to go back to client with any other handlers in the phase, as well as later phases being skipped. Returning DONE is much like returning an error but Apache interprets it as meaning a complete respon
se was constructed and that it doesn't have to generate any response.
For the AP_IMPLEMENT_HOOK_RUN_FIRST macro, all handlers will be run only if they all return DECLINED. In other words, if a handler returns OK it will skip the following handlers in that phase and then move onto the next phase. Returning an error or DONE i
s like above.
In the case of mod_python, what it does doesn't fit into either. It is closer to behaving like the AP_IMPLEMENT_HOOK_RUN_ALL macro except that it stops processing further handlers in the phase if DECLINED is returned.
As to what problems this causes, imagine you had registered multiple authentication handlers which supported different authentication mechanisms. This is the case where AP_IMPLEMENT_HOOK_RUN_FIRST macro is used. The idea is that each authentication handl
er would check the value associated with the AuthType directive to determine if it should do anything. If it was not the AuthType it implements, if it were a C based handler module, it would returned DECLINED to indicate it hadn't done anything and that t
he next handler should instead be tried. Each handler would thus be called until one handler says that is for me, says the user is valid and returns OK or returns an error rejecting it.
If you wanted to write these multiple authentication handlers in Python you can't do it. This is because the way mod_python works, if you return DECLINED it would actually skip the remainder of the mod_python declared handlers whereas you still want them
to be executed. Apache would still execute any other C based handlers in the phase though. The only way to get mod_python to execute later mod_python handlers in the phase is to return OK, but if you do that and it happens to be the last handler in the mo
d_python list of handlers, it will return OK to Apache and Apache will then think a handler successfully handled it and not then execute any subsequent C based handlers in that phase.
There are going to be other sorts of problems with phases implemented using AP_IMPLEMENT_HOOK_RUN_ALL as well, as a handler that validly returns DECLINED to say it didn't do anything will cause mod_python to skip later mod_python handlers as well. If it w
ere only C based handlers, that wouldn't be the case.
In summary, it doesn't work how it probably should.
Note that the above relates to phases other than content handler. Still have to work out what Apache does for content handler phase when there are multiple handlers for the phase.
No one has probably noticed these problems as no one seems to use mod_python in a serious way for implementing these other phases, simply using mod_python as a jumping off point for content handlers.
was:
Todays daily bug report, or is it? ;-)
The Python*Handler documentation says:
"""Multiple handlers can be specified on a single line, in which case they will be called sequentially, from left to right. Same handler directives can be specified multiple times as well, with the same result - all handlers listed will be executed sequen
tially, from first to last. If any handler in the sequence returns a value other than apache.OK, then execution of all subsequent handlers is aborted."""
That is, no matter which phase is being processed, mod_python will stop processing them if a value other than OK is returned.
Problem is that this isn't how Apache itself treats the result from handlers. Apache actually implements two different ways for dealing with the result from the handlers. Which is used depends on which processing phase is occuring. This is all specified b
y the Apache magic macro code:
AP_IMPLEMENT_HOOK_RUN_FIRST(int,translat
e_name,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,map_to_s
torage,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,check_us
er_id,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,auth_che
cker,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int,access_che
cker,
(request_rec *r), (r), OK, DECLINED)
AP_IMPLEMENT_HOOK_RUN_FIRST(int,type_che
cker,
(request_rec *r), (r), DECLINED)
AP_IMPLEMENT_HOOK_RUN_ALL(int,fixups,
(request_rec *r), (r), OK, DECLINED)
What this gobblegook expands to are loops which will stop processing handlers based on the result.
For the AP_IMPLEMENT_HOOK_RUN_ALL macro, all handlers in the phase will be run unless one returns something other than OK or DECLINED. Returning OK means that it did something and it worked okay. Returing DECLINED means that it didn't do anything at all.
In both these cases, it still goes onto the next handler in that phase. After that it will go onto the next phase.
Returning an error will cause appropriate error response to go back to client with any other handlers in the phase, as well as later phases being skipped. Returning DONE is much like returning an error but Apache interprets it as meaning a complete respon
se was constructed and that it doesn't have to generate any response.
For the AP_IMPLEMENT_HOOK_RUN_FIRST macro, all handlers will be run only if they all return DECLINED. In other words, if a handler returns OK it will skip the following handlers in that phase and then move onto the next phase. Returning an error or DONE i
s like above.
In the case of mod_python, what it does doesn't fit into either. It is closer to behaving like the AP_IMPLEMENT_HOOK_RUN_ALL macro except that it stops processing further handlers in the phase if DECLINED is returned.
As to what problems this causes, imagine you had registered multiple authentication handlers which supported different authentication mechanisms. This is the case where AP_IMPLEMENT_HOOK_RUN_FIRST macro is used. The idea is that each authentication handl
er would check the value associated with the AuthType directive to determine if it should do anything. If it was the AuthType it implements, if it were a C based handler module, it would returned DECLINED to indicate it hadn't done anything and that the n
ext handler should instead be tried. Each handler would thus be called until one handler says that is for me, says the user is valid and returns OK or returns an error rejecting it.
If you wanted to write these multiple authentication handlers in Python you can't do it. This is because the way mod_python works, if you return DECLINED it would actually skip the remainder of the mod_python declared handlers whereas you still want them
to be executed. Apache would still execute any other C based handlers in the phase though. The only way to get mod_python to execute later mod_python handlers in the phase is to return OK, but if you do that and it happens to be the last handler in the mo
d_python list of handlers, it will return OK to Apache and Apache will then think a handler successfully handled it and not then execute any subsequent C based handlers in that phase.
There are going to be other sorts of problems with phases implemented using AP_IMPLEMENT_HOOK_RUN_ALL as well, as a handler that validly returns DECLINED to say it didn't do anything will cause mod_python to skip later mod_python handlers as well. If it w
ere only C based handlers, that wouldn't be the case.
In summary, it doesn't work how it probably should.
Note that the above relates to phases other than content handler. Still have to work out what Apache does for content handler phase when there are multiple handlers for the phase.
No one has probably noticed these problems as no one seems to use mod_python for implementing these other phases, simply using mod_python as a jumping off point for content handlers.
Missed a "not" in an important place again. :-)
> HandlerDispatch doesn't treat OK/DECLINED result properly for all phases.
> -------------------------------------------------------------------------
>
> Key: MODPYTHON-129
> URL: http://issues.apache.org/jira/browse/MODPYTHON-129
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2
> Reporter: Graham Dumpleton
>
> Todays daily bug report, or is it? ;-)
> The Python*Handler documentation says:
> """Multiple handlers can be specified on a single line, in which case they will be called sequentially, from left to right. Same handler directives can be specified multiple times as well, with the same result - all handlers listed will be executed sequ
entially, from first to last. If any handler in the sequence returns a value other than apache.OK, then execution of all subsequent handlers is aborted."""
> That is, no matter which phase is being processed, mod_python will stop processing them if a value other than OK is returned.
> Problem is that this isn't how Apache itself treats the result from handlers. Apache actually implements two different ways for dealing with the result from the handlers. Which is used depends on which processing phase is occuring. This is all specified
by the Apache magic macro code:
> AP_IMPLEMENT_HOOK_RUN_FIRST(int,translat
e_name,
> (request_rec *r), (r), DECLINED)
> AP_IMPLEMENT_HOOK_RUN_FIRST(int,map_to_s
torage,
> (request_rec *r), (r), DECLINED)
> AP_IMPLEMENT_HOOK_RUN_FIRST(int,check_us
er_id,
> (request_rec *r), (r), DECLINED)
> AP_IMPLEMENT_HOOK_RUN_FIRST(int,auth_che
cker,
> (request_rec *r), (r), DECLINED)
> AP_IMPLEMENT_HOOK_RUN_ALL(int,access_che
cker,
> (request_rec *r), (r), OK, DECLINED)
> AP_IMPLEMENT_HOOK_RUN_FIRST(int,type_che
cker,
> (request_rec *r), (r), DECLINED)
> AP_IMPLEMENT_HOOK_RUN_ALL(int,fixups,
> (request_rec *r), (r), OK, DECLINED)
> What this gobblegook expands to are loops which will stop processing handlers based on the result.
> For the AP_IMPLEMENT_HOOK_RUN_ALL macro, all handlers in the phase will be run unless one returns something other than OK or DECLINED. Returning OK means that it did something and it worked okay. Returing DECLINED means that it didn't do anything at all
. In both these cases, it still goes onto the next handler in that phase. After that it will go onto the next phase.
> Returning an error will cause appropriate error response to go back to client with any other handlers in the phase, as well as later phases being skipped. Returning DONE is much like returning an error but Apache interprets it as meaning a complete resp
onse was constructed and that it doesn't have to generate any response.
> For the AP_IMPLEMENT_HOOK_RUN_FIRST macro, all handlers will be run only if they all return DECLINED. In other words, if a handler returns OK it will skip the following handlers in that phase and then move onto the next phase. Returning an error or DONE
is like above.
> In the case of mod_python, what it does doesn't fit into either. It is closer to behaving like the AP_IMPLEMENT_HOOK_RUN_ALL macro except that it stops processing further handlers in the phase if DECLINED is returned.
> As to what problems this causes, imagine you had registered multiple authentication handlers which supported different authentication mechanisms. This is the case where AP_IMPLEMENT_HOOK_RUN_FIRST macro is used. The idea is that each authentication han
dler would check the value associated with the AuthType directive to determine if it should do anything. If it was not the AuthType it implements, if it were a C based handler module, it would returned DECLINED to indicate it hadn't done anything and that
the next handler should instead be tried. Each handler would thus be called until one handler says that is for me, says the user is valid and returns OK or returns an error rejecting it.
> If you wanted to write these multiple authentication handlers in Python you can't do it. This is because the way mod_python works, if you return DECLINED it would actually skip the remainder of the mod_python declared handlers whereas you still want the
m to be executed. Apache would still execute any other C based handlers in the phase though. The only way to get mod_python to execute later mod_python handlers in the phase is to return OK, but if you do that and it happens to be the last handler in the
mod_python list of handlers, it will return OK to Apache and Apache will then think a handler successfully handled it and not then execute any subsequent C based handlers in that phase.
> There are going to be other sorts of problems with phases implemented using AP_IMPLEMENT_HOOK_RUN_ALL as well, as a handler that validly returns DECLINED to say it didn't do anything will cause mod_python to skip later mod_python handlers as well. If it
were only C based handlers, that wouldn't be the case.
> In summary, it doesn't work how it probably should.
> Note that the above relates to phases other than content handler. Still have to work out what Apache does for content handler phase when there are multiple handlers for the phase.
> No one has probably noticed these problems as no one seems to use mod_python in a serious way for implementing these other phases, simply using mod_python as a jumping off point for content handlers.
|