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
>
>