Calling usage() from the rewrite args hook?

[Rainer Jung <ra...@kippdata.de>]

While working on additional windows commandline options I noticed, that
there is no consistent checking for validity of the "-k" arguments.

Those arguments are handled by the rewrite args hook, and some MPMs seem
to care somehow about invalid or duplicate "-k" arguments (e.g. Unix
outputs a somewhat wrong error message about -k being unknown), windows
seems to start the service when an unknown command is given.

I would like to output a better error message for unknown or duplicate
commands (easy) and then call usage(). At the moment usage() is static
in main.c and there is not a single header file directly in the server/
directory.

So I would like to add a private header file in the server directory, at
the moment only containing usage() and switch usage() from static to
AP_DECLARE. Would that be right? I guess we have no reason to include it
in the public include files contained in includes/.

Another possibility would be to let the rewrite args hook return a
value, stop processing as soon as one module doesn't return OK and call
the usage whenever rewrite args for a module do not return OK. I think
that's a bit fragile, because in the long run, more return values might
show up and cases, where usage() is not the right way to react, so
making usage() available in the mpm-specific module argument handling
seems to be the better way.

Of course the usage message at the moment doesn't really reflect the MPM
architecture. The commandline specialities are reflected by ifdefs in
the usage, but that's another topic. For the above needed hardening of
parsing the -k flags, the usage message as it exists today is enough.

Comments?

Regards,

Rainer

Re: Calling usage() from the rewrite args hook?

[Ruediger Pluem <rp...@apache.org>]

On 05/06/2009 10:13 PM, Rainer Jung wrote:
> On 06.05.2009 21:33, Rainer Jung wrote:
>> While working on additional windows commandline options I noticed, that
>> there is no consistent checking for validity of the "-k" arguments.
>>
>> Those arguments are handled by the rewrite args hook, and some MPMs seem
>> to care somehow about invalid or duplicate "-k" arguments (e.g. Unix
>> outputs a somewhat wrong error message about -k being unknown), windows
>> seems to start the service when an unknown command is given.
>>
>> I would like to output a better error message for unknown or duplicate
>> commands (easy) and then call usage(). At the moment usage() is static
>> in main.c and there is not a single header file directly in the server/
>> directory.
>>
>> So I would like to add a private header file in the server directory, at
>> the moment only containing usage() and switch usage() from static to
>> AP_DECLARE. Would that be right? I guess we have no reason to include it
>> in the public include files contained in includes/.
>>
>> Another possibility would be to let the rewrite args hook return a
>> value, stop processing as soon as one module doesn't return OK and call
>> the usage whenever rewrite args for a module do not return OK. I think
>> that's a bit fragile, because in the long run, more return values might
>> show up and cases, where usage() is not the right way to react, so
>> making usage() available in the mpm-specific module argument handling
>> seems to be the better way.
>>
>> Of course the usage message at the moment doesn't really reflect the MPM
>> architecture. The commandline specialities are reflected by ifdefs in
>> the usage, but that's another topic. For the above needed hardening of
>> parsing the -k flags, the usage message as it exists today is enough.
>>
>> Comments?
> 
> While experimenting with that: on Windows mpm_winnt.c can't use
> something in main.c, only vice versa. So usage() would have to be moved
> from main.c into any other file included in libhttpd (or a new one).
> Still the question is: is this the right way to go? If so, should I add
> a small new file with usage(), since the names of the existing ones do
> not really make a good fit?

How about the existing util.c?

Regards

Rüdiger

Re: Calling usage() from the rewrite args hook?

[Rainer Jung <ra...@kippdata.de>]

On 06.05.2009 21:33, Rainer Jung wrote:
> While working on additional windows commandline options I noticed, that
> there is no consistent checking for validity of the "-k" arguments.
> 
> Those arguments are handled by the rewrite args hook, and some MPMs seem
> to care somehow about invalid or duplicate "-k" arguments (e.g. Unix
> outputs a somewhat wrong error message about -k being unknown), windows
> seems to start the service when an unknown command is given.
> 
> I would like to output a better error message for unknown or duplicate
> commands (easy) and then call usage(). At the moment usage() is static
> in main.c and there is not a single header file directly in the server/
> directory.
> 
> So I would like to add a private header file in the server directory, at
> the moment only containing usage() and switch usage() from static to
> AP_DECLARE. Would that be right? I guess we have no reason to include it
> in the public include files contained in includes/.
> 
> Another possibility would be to let the rewrite args hook return a
> value, stop processing as soon as one module doesn't return OK and call
> the usage whenever rewrite args for a module do not return OK. I think
> that's a bit fragile, because in the long run, more return values might
> show up and cases, where usage() is not the right way to react, so
> making usage() available in the mpm-specific module argument handling
> seems to be the better way.
> 
> Of course the usage message at the moment doesn't really reflect the MPM
> architecture. The commandline specialities are reflected by ifdefs in
> the usage, but that's another topic. For the above needed hardening of
> parsing the -k flags, the usage message as it exists today is enough.
> 
> Comments?

While experimenting with that: on Windows mpm_winnt.c can't use
something in main.c, only vice versa. So usage() would have to be moved
from main.c into any other file included in libhttpd (or a new one).
Still the question is: is this the right way to go? If so, should I add
a small new file with usage(), since the names of the existing ones do
not really make a good fit?

Regards,

Rainer