httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: module status
Date Sat, 03 Aug 1996 12:30:26 GMT
On 3 Aug 1996 03:14:55 +0200 in en.lists.apache-new-httpd you wrote:

> We have discussed recently, and there has been sufficient interested in,
> including modified versions of mod_rewrite and mod_xinclude in Apache 1.2.
> The authors of those modules agreed to rewrite the modules as neccessary.
> I was wondering if we could get a status report from them? August 11,
> which I gave as the "stop adding stuff to Apache 1.2" date a couple weeks
> ago, is only ten days away.

Hmmm...  I've modified mod_rewrite for v2.1 according to your requests.
Below is my current v2.1 changelog appended.  But I still have some problems.

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]

   [PS: No, mod_action could not be used, because the PATH_INFO for
        the called programs have to be in a special format!]

   The first one sends all *.scgi files through the popular CGIwrap
   CGI-program.  The rewriting is needed, because the URL
   /u/rse/.www/abc/x.scgi has to be passed to CGIwrap as /~rse/abc/x.scgi.
   Now consider the second rule: This is a similar one. It just send all
   *.phtml files directly through my eperl CGI-program (a Embedded Perl for
   HTML interpreter). This does work fine when I reference e.g. the URL

   And now comes the problem: Consider a directory /u/rse/.www/abc/ where
   there is either a index.scgi or a index.phtml (both are contained in the
   DirectoryIndex list of mod_dir).

   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.

   I traced this back 4 hours yesterday and it seems exactly that the core
   dump only occurs in the following situation:

   - All your *.yyy files are rewritten so they get process via 
     some CGI-script, i.e. the path *.yyy gets the PATH_INFO part
     because it is prefixed by the path of the CGI-script.
   - The generated PATH_INFO part is a _real one_, i.e. it is
     a valid filename. [THIS IS THE POINT! BUT I DON'T KNOW WHY..]
   - You have index.yyy in the DIrectoryIndex list of mod_dir
   - You have a dir .../anydir/ where a index.yyy file resides.
   - Referencing ".../anydir/" will cause a core dump
   - Referencing ".../anydir/" will work 
   but: When the PATH_INFO part is not a valid path, then
        no core dumps occur and it works (even if the CGI-script allways just
        outputs some test string and actually ignores the PATH_INFO, i.e. the
        problem is not the CGI-script).

   Seems to me very crazy! Any ideas?

   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.

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. 

   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.

        (Ok, I know the long discussion about the regex stuff, but 
        I thought it would be no problem, but now I discovered that
        the current way of inclusion is not optional due to the allways
        used declarations! These should be optional, too.)

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.

                                        Ralf S. Engelschall    

  V2.1 960722 - added RewriteLogLevel directive to be able to adjust
                the amount of logfile verbosity (0=none .. 9=max)

              - now there is no default rewriting logfile

       960728 - replaced some remaining strdup() with pstrdup()

              - changed some local character array of size MAX_STRING_LEN
                (which get allocated on the stack) to static ones (which
                usually get allocated in global memory pool but with local
                scope. I think replacing it with palloc() memory will slow
                down the process.

              - made directives "RewriteLog", "RewriteLogLevel" and
                "RewriteMap" only valid for per-server configuration, because
                they were still ignored in per-directory contenxt and
                although it can be useful to have special per-directory
                logfiles, this produces to much overhead and slows down the
                process. And perhaps it can be risky for the admin to allow
                such things in per-dir context.

              - re-sorted the functions inside the module and
                added another great bulk of comments. Now the source again is
                in very clear state.

              - !! BIG INTERNAL CHANGE !!
                Now we no longer operate on r->uri directly!  Now mod_rewrite
                does a initial transition from r->uri to r->filename and then
                only operates on r->filename.
                => This is the correct way !
                => This fixes some problems with imagemap redirects
                   where prior some filename stuff was incorrectly included!
                [Thanks to Alexei Kosut for pushing me to fix this
                 long standing problem ;-)]

              - now the tilde-paths "/~user/..." are only expanded
                at the end of rewriting process and only if the result will
                lead to either a redirect or a proxy throughput. 
                => This fixes the tidle expansions which occured at
                   the wrong time in someones RewriteRules.
                [Thanks to Sami Laine <> and Roman Pozlevich
                <> for discovering this problem]

       960802 - ...

View raw message