httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <ruediger.pl...@vodafone.com>
Subject AW: svn commit: r559837 - /httpd/httpd/trunk/modules/filters/mod_filter.c
Date Fri, 27 Jul 2007 07:38:14 GMT


> -----Ursprüngliche Nachricht-----
> Von: Nick Kew 
> Gesendet: Donnerstag, 26. Juli 2007 23:20
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r559837 - 
> /httpd/httpd/trunk/modules/filters/mod_filter.c

> Agreed.  I'm happy with the changes you imply in this and your
> other post.
> 
> On the other hand, removing the check might risk segfaulting in some
> future update - perhaps something that gets configuration per-request
> from a database and a rewritemap.  I've recently had a similar issue
> with another module, which started life using match rules defined in
> httpd.conf, then grew to derive them from rewritemap+dbm.  Worked
> fine until it constructed a match-rule from a corrupted 
> database entry.

Ok, so it is a "better safe then sorry" approach. I am fine with this.
I just wanted to clarify if I missed something obvious at the current
state that makes these checks necessary :-).
So I think it is good to have the checks, but as the conditions should not
become true (provider->match.string should not be NULL in these cases)
I think it would be good to emit additionally an error message in these cases,
as something seems to be rotten then.
So the only point that remains is checking for match.regex in front of
the regular expression for the sake of clarity.


Regards

Rüdiger


Mime
View raw message