You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by si...@us.ibm.com on 2000/08/09 18:55:50 UTC
mod_cern_meta
Hi,
I'm forwarding a note I received from someone I work with here. She has a
couple questions on mod_cern_meta for Apache 2.0. Anyone have an answer?
Thanks.
--------------------------------------------------------
Rob,
I have found two problems in mod_cern_meta...
In the scan_meta_file procedure, a successful read of the file is ignored
because the while loop is checking for the return from ap_fgets !=
APR_SUCCESS. This looks like a carry-over from when fgets was checked
for a non-NULL return.
There two values for the MetaFiles directive appear to be treated the same
- MetaFiles On and MetaFiles Off do not differentiate how the request is
handled - the server looks for a meta file either way. Either the
dir_config is being set incorrectly, or the hook needs to check more than
NULL or non-NULL.
--------------------------------------------------------
Rob Simonson
simo@us.ibm.com
Re: mod_cern_meta
Posted by Jeff Trawick <tr...@bellsouth.net>.
I have no reason to disagree with Bill on the lifetime of
mod_cern_meta, so consider that somebody may yank it out of
Apache.
simo@us.ibm.com writes:
> Hi,
>
> I'm forwarding a note I received from someone I work with here. She has a
> couple questions on mod_cern_meta for Apache 2.0. Anyone have an answer?
> Thanks.
>
> --------------------------------------------------------
>
> Rob,
>
> I have found two problems in mod_cern_meta...
>
> In the scan_meta_file procedure, a successful read of the file is ignored
> because the while loop is checking for the return from ap_fgets !=
> APR_SUCCESS. This looks like a carry-over from when fgets was checked
> for a non-NULL return.
O.k., I'll put in this simple fix.
> There two values for the MetaFiles directive appear to be treated the same
> - MetaFiles On and MetaFiles Off do not differentiate how the request is
> handled - the server looks for a meta file either way. Either the
> dir_config is being set incorrectly, or the hook needs to check more than
> NULL or non-NULL.
I put a stylistic fix in a few days ago which initially looked to me
like a real bug fix: set_metafiles() treated the boolean flag as char
* instead of int and it was maintained as char * in the dir config.
It looked weird and initially I suspected broken-ness. However, a
value of NULL for the pointer corresponded to MetaFiles off and a
value of 1 for the pointer corresponded to MetaFiles on.
Is this what you are concerned with or is it something else?
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: mod_cern_meta
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
Hummm.... I am thinking mod_cern_meta should be retired. Use mod_headers instead.
mod_headers is much more efficient as it does not need to open files to get the header
info.
Bill
----- Original Message -----
From: <si...@us.ibm.com>
To: <ne...@us.ibm.com>
Sent: Wednesday, August 09, 2000 12:55 PM
Subject: mod_cern_meta
> Hi,
>
> I'm forwarding a note I received from someone I work with here. She has a
> couple questions on mod_cern_meta for Apache 2.0. Anyone have an answer?
> Thanks.
>
> --------------------------------------------------------
>
> Rob,
>
> I have found two problems in mod_cern_meta...
>
> In the scan_meta_file procedure, a successful read of the file is ignored
> because the while loop is checking for the return from ap_fgets !=
> APR_SUCCESS. This looks like a carry-over from when fgets was checked
> for a non-NULL return.
>
> There two values for the MetaFiles directive appear to be treated the same
> - MetaFiles On and MetaFiles Off do not differentiate how the request is
> handled - the server looks for a meta file either way. Either the
> dir_config is being set incorrectly, or the hook needs to check more than
> NULL or non-NULL.
>
> --------------------------------------------------------
>
> Rob Simonson
> simo@us.ibm.com
>
>