You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@opengroup.org> on 1997/05/31 00:55:45 UTC
b11 + mod_perl + BrowserMatch
I just confirmed on a linux box, that httpd croaks with mod_perl and
the default config:
BrowserMatch Mozilla/2 nokeepalive
Comment it out, no troubles.
It does not croak either way with b10.
After an exchange with Mike Fletcher, looks like the link order change
in Makefile.tmpl caused the breakage somehow:
*** Makefile.tmpl.b10 Fri May 30 18:39:07 1997
--- Makefile.tmpl.b11 Fri May 30 18:39:21 1997
***************
*** 26,32 ****
@false
httpd: $(REGLIB) $(OBJS)
! $(CC) $(LFLAGS) -o httpd $(OBJS) $(REGLIB) $(LIBS)
regex/libregex.a:
(cd regex; $(MAKE) lib CC=$(CC) AUX_CFLAGS='$(CFLAGS)' RANLIB='$(RANLIB)')
--- 26,32 ----
@false
httpd: $(REGLIB) $(OBJS)
! $(CC) $(LFLAGS) -o httpd $(OBJS) $(LIBS) $(REGLIB)
regex/libregex.a:
(cd regex; $(MAKE) lib CC=$(CC) AUX_CFLAGS='$(CFLAGS)' RANLIB='$(RANLIB)')
Building b11 with the b10 Makefile.tmpl cures the problem for myself
and Mike.
I recall this change being mentioned on the apache developer's list,
but I can't recall why. I can't dig deeper until later this weekend.
-Doug
Re: b11 + mod_perl + BrowserMatch
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 31 May 1997, Rasmus Lerdorf wrote:
> There are still compatibility differences between hsregex and
> conventional Posix regex libs though. For example. This bit of code only
> works with hsregex:
>
> subs[0].rm_so = i;
> subs[0].rm_eo = l;
> err = regexec(&re, string, (size_t)NS, subs, REG_STARTEND);
>
> To do the same thing with the stock system regex libs on most OS'es you
> would need to do something like:
That's not a "compatibility difference," it's a feature of the Spencer
regex package. The code you give for "stock" regexes works with
Spencers, right? As far as I'm aware, the POSIX regex spec doesn't
specify REG_STARTEND, that's a Spencerism.
[...]
> Yes, this is a recurring problem with mod_php. If when libphp.a is
> compiled for hsregex and Apache is linked with the system's Posix regex or
> vice versa, httpd consistently core dumps. I have warnings about this all
> over the PHP installation telling people to make sure that if they tell
> PHP they are going to be using hsregex, to specifically set WANTHSREGEX in
> the Apache Configuration file to 'yes'. And to 'no' if they compile PHP
> to use the system regex lib.
Hmm. We should change this for the Apache 2.0 API: Don't let modules
call any of the regex functions by hand. Wrap them in Apache
functions. Even though could just be
int apache_regexec(regex_t *preg, char *string, size_t nmatch, regmatch_t
pmatch[], int eflags) {
regexec(preg, string, nmatch, pmatch, eflags);
}
it would make life easier for you and other writers of large
module-libraries, right?
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: b11 + mod_perl + BrowserMatch
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> That can't be right; Spencer's libs are POSIX regex libs. They are, in
> fact, used as such in some OSes (such as FreeBSD, if I recall
> correctly). mod_browser should work just fine with either. I don't see
> a check for regex library anywhere in mod_rewrite; at least, not the
> version that's bundled with Apache. Can you be more specific?
> Certainly, there are still some parts of mod_rewrite left over from
> when it ran with both POSIX regex and the V8 regex, which may be what
> you're thinking of.
Right, it was the V8 regex vs. POSIX checks still in mod_rewrite I was
thinking of.
There are still compatibility differences between hsregex and
conventional Posix regex libs though. For example. This bit of code only
works with hsregex:
subs[0].rm_so = i;
subs[0].rm_eo = l;
err = regexec(&re, string, (size_t)NS, subs, REG_STARTEND);
To do the same thing with the stock system regex libs on most OS'es you
would need to do something like:
oo = string[l];
string[l] = '\0';
err = regexec(&re, &string[i], (size_t)NS, subs, 0);
string[l] = oo;
subs[0].rm_so += i;
subs[0].rm_eo += i;
> Of course, Apache and any added-on libraries that use regexes have to
> be sure to use the same library if the OS has a built-in regex
> library, but Apache is using Spencer's. Otherwise life gets a bit
> wacky. This may be what's happening with mod_perl.
Yes, this is a recurring problem with mod_php. If when libphp.a is
compiled for hsregex and Apache is linked with the system's Posix regex or
vice versa, httpd consistently core dumps. I have warnings about this all
over the PHP installation telling people to make sure that if they tell
PHP they are going to be using hsregex, to specifically set WANTHSREGEX in
the Apache Configuration file to 'yes'. And to 'no' if they compile PHP
to use the system regex lib.
-Rasmus
Re: b11 + mod_perl + BrowserMatch
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Fri, 30 May 1997 rasmus@bellglobal.com wrote:
> That was my doing. I don't understand why this would break anything.
> The PHP module needs a regex library. If WANTHSREGEX is set to 'yes' in
> the Apache Configuration file and the bundled regex library is used in
> Apache, then the PHP module tries to use this library as well. In order
> to use this the -lregex library call must come after the -lphp call. ie.
> $(LIBS) must precede $(REGLIB).
>
> I have a feeling there is something funny in mod_browser.c and its use of
> case insensitive regex expressions. I seem to recall that this has to be
> handled differently in Posix regex libs as opposed to the Henry Spencer lib.
> I see no distinction made in mod_browser.c. mod_rewrite.c seems to have a
> check for this.
That can't be right; Spencer's libs are POSIX regex libs. They are, in
fact, used as such in some OSes (such as FreeBSD, if I recall
correctly). mod_browser should work just fine with either. I don't see
a check for regex library anywhere in mod_rewrite; at least, not the
version that's bundled with Apache. Can you be more specific?
Certainly, there are still some parts of mod_rewrite left over from
when it ran with both POSIX regex and the V8 regex, which may be what
you're thinking of.
Of course, Apache and any added-on libraries that use regexes have to
be sure to use the same library if the OS has a built-in regex
library, but Apache is using Spencer's. Otherwise life gets a bit
wacky. This may be what's happening with mod_perl.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: b11 + mod_perl + BrowserMatch
Posted by ra...@bellglobal.com.
> Building b11 with the b10 Makefile.tmpl cures the problem for myself
> and Mike.
> I recall this change being mentioned on the apache developer's list,
> but I can't recall why. I can't dig deeper until later this weekend.
That was my doing. I don't understand why this would break anything.
The PHP module needs a regex library. If WANTHSREGEX is set to 'yes' in
the Apache Configuration file and the bundled regex library is used in
Apache, then the PHP module tries to use this library as well. In order
to use this the -lregex library call must come after the -lphp call. ie.
$(LIBS) must precede $(REGLIB).
I have a feeling there is something funny in mod_browser.c and its use of
case insensitive regex expressions. I seem to recall that this has to be
handled differently in Posix regex libs as opposed to the Henry Spencer lib.
I see no distinction made in mod_browser.c. mod_rewrite.c seems to have a
check for this.
I only had a 2 minute look at this. I am no my way out the door. I'll look
at it closely tomorrow.
-Rasmus