httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: module status
Date Sat, 03 Aug 1996 19:35:10 GMT
On Sat, 3 Aug 1996, Ralf S. Engelschall wrote:

[...]

> 1. Due to the change "never change r->uri" there is a difficult
>    problem inside Apache 1.1.1: It dumps core under a _very special_
>    situation. Have a look at the following two rules:
> 
>    RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*)  ...
>                ...  /internal/cgi/user/cgiwrap/~$1/$2.scgi$3  [NS]
>    RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.phtml(.*) ...
>                ...  /internal/cgi/user/eperl/u/$1/.www/$2.phtml$3  [NS]

[...]

>    When I reference /u/rse/abc/index.scgi directly it works.
>    When I reference /u/rse/abc/ and there is the index.scgi it works.
>    When I reference /u/rse/abc/index.phtml directly it works.
>    When I reference /u/rse/abc/ and there is the index.phtml it dumps core.

This may be related to the SCRIPT_NAME problem that was reported a week or
so ago. Here's something you might check: See what the value of
path_info_start is at line 215 of util_script.c (in add_cgi_vars()). I
have a feeling it might be negative. If so, it's a problem with the core
code, don't worry about it, hopefully we'll fix it.

[...]

>    BTW: What is the best way to debug Apache? OK, I now -X but when I tried
>         to catch the above core dump then this didn't worked for my gdb under
>         FreeBSD 2.1.0! gdb never sees the core when I use "gdb ./httpd" and
>         then "run -X". The only way to successfully debug was the good old
>         "fprintf(stderr, .." method. But for this problem this is horrible.

Hmm. Running httpd -X under various debuggers always works for me.

> 2. I've done a first shot to use the new regex code of the latest snapshots but
>    the old regexp strings of my RewriteRule directives no longer matched!
>    I've put this problem to the second level of my fixing process, because I
>    think it is only a little bug somewhere. 

Could be a slight different in the regex syntaxes. Did you use
REG_EXTENDED? It's probably a lot closer to the V8 syntax than REG_BASIC.

>    BTW: With the current regex stuff of Apache it is not possible to
>         compile in any module or stuff which uses a different regex library
>         when this different regexp library conflicts with the prototypes of
>         regex.h from the Apache distribtion. Becuase regex.h is included in
>         conf.h and even commenting it out does not work, becuase it is needed
>         for alloc.* etc. I think it would be better to have some sort of
>         USE_INTERNAL_REGEX and sorround all regex stuff in Apache, i.e.
>         if you don't want to use the stuff Apache should not even try to
>         declare the stuff in alloc.h and utils.c etc.

I disagree. We've included that nice regex code, people should be forced
to use it :P

At any rate, hopefully you can get mod_rewrite to work; I certainly don't
want to have to include *two* regex libraries in Apache.

[...]

> 3. Using mod_alias _AND_ mod_rewrite does (because of 1.) no longer
>    work, because the current API has no support for such situations, i.e.  a
>    hook for URI-to-URI or filename-to-filename conversion. Currently you have
>    to use mod_rewrite_compat.c if you really want to mix RewriteRule, Alias,
>    ScriptAlias and Redirect directives. We discussed this recently and the
>    only solution to this is to add two new hooks to the API: One for
>    URI-to-URI-rewriting, the other for Filename-to-Filename rewriting.  I
>    will add a special flag to RewriteRules which one can use to manually
>    force the current filename to overrrite the r->uri. This is just a hack
>    unless we have a better API, but this can be a workaround for those who
>    really want to mix the directives.

That sounds fine.

> Comments?

Sounds good. If you want some help, or you want someone else to look over
the code, feel free to post it here or make it available somewhere.

-- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
   http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/


Mime
View raw message