Re: [PATCH] mod_mime.c core dumps with no AddType

[William A. Rowe, Jr.]

From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Wednesday, August 22, 2001 3:19 PM


> sterling <[EMAIL PROTECTED]> writes:
> 
> > this patch should fix the crash, but IMHO by that point the
> > extension_mappings hash should just be empty, not null (i.e. it should be
> > initialized to apr_hash_make) --
> 
> +1 to a patch which initializes apr_hash_make() more sanely so we
> don't have to keep checking

-1 until we revert to tables.

Re: [PATCH] mod_mime.c core dumps with no AddType

[William A. Rowe, Jr.]

From: "sterling" <[EMAIL PROTECTED]>


> It appears that the extension_mappings hash is initialized to null, then
> only instanciated if there is an AddType call in your conf file.  Hence in
> the type_checker phase it tries to perform a lookup on a null hash.
>
> this patch should fix the crash, but IMHO by that point the
> extension_mappings hash should just be empty, not null (i.e. it should be
> initialized to apr_hash_make) --

No ... it should not.

Even an empty hash must be merged in merge_per_dir_configs ... and that's
very time consuming.

Bill

Re: Letting Table store non-char data

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 2:37 AM


> On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> > Greg Stein wrote:
> >...
> > >Yes there is. apr_pool_userdata_set(..., r->pool)
> >...
> > Using the "userdata" functions on r->pool as a replacement for a
> > hash-based r->notes would be a mistake.  The interface to the userdata
> > in a pool is limited to "get" and "set" methods.  The API is missing
> > essential operations like "iterate over the set of elements in the userdata"
> > and "merge the userdata for a subrequest pool into the parent's r->pool."
> 
> I would posit those operations are not needed. The notes or userdata are for
> specific bits of information. It is not a simple collection that you can
> iterate over. In fact, since you can't know the values of each key, you
> cannot perform a useful iteration nor do a useful merge.

Precisely.

What negative consequences would that pose for subrequests?

Re: Location of /manual

[William A. Rowe, Jr.]

From: "Martin Kraemer" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:52 AM


> In the configuration file, we have:
> 
> > #
> > # This should be changed to the ServerRoot/htdocs/manual/.  The alias provides
> > # the manual, even if you choose to move your DocumentRoot.  You may comment
> > # this out if you do not care for the documentation.
> > #
> > Alias /manual "@@ServerRoot@@/htdocs/manual"
> > 
> > 
> > Options Indexes FollowSymLinks MultiViews
> 
> By doing it this way, we make it easy for end users to modify the
> DocumentRoot to separate their contents from the manual's, but we
> make it difficult if they choose to replace the contents in the
> @@ServerRoot@@/htdocs directory directly.
> 
> I would propose to handle /manual quite similar to /icons as a read-only
> resource which is part of the server, not part of the documentroot.
> 
> In other words, I propose to move /manual up one directoryy level,
> side by side with /icons:
>@@ServerRoot@@/htdocs/...
>@@ServerRoot@@/icons/...
>@@ServerRoot@@/manual/...

++1

> Then we really don't need to worry about overwriting the /manual
> directory during installation (we don't for /icons either, but we
> have been careful with /htdocs at least in Apache 1.3).
> 
> Thanks to the Alias, no end-user-change is visible. but we get a
> much better separation.

Agreed.  Make is so (even the Makefile.win change should be simple :)

Re: 2.0.24 ready for beta?

[William A. Rowe, Jr.]

We must (temporarily) disable the /error/ mapping section, until we can set


ForceLanguagePreferences Full

because right now you can get a Not Acceptable [list of identical files] that
they can't decypher.  I should be wrapped up tommorow, but I've been seriously
sidelined by bigger fish...

The filesystem is also still full of holes that I've (nearly) fixed in my
checked out tree.  The patch I'm committing closes 90% up, and discovers
10% new ones we need to fix.  It eliminates reliance on os/foo/os.c for the
is_absolute and canonical stuff that's broken on non-unix.

I'm -1 on calling any Win32 release a beta without those eliminated.  Hold
on while I summon up the commits.

Bill

- Original Message - 
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 10:09 AM
Subject: 2.0.24 ready for beta?


> With the last mod_include fix, can we bump the tag on mod_include and go beta?
> 
> Bill
> 
> 

Re: MSI Installer

[William A. Rowe, Jr.]

Right now, that's all built in InstallShield for Windows Installer 2.0 (ISWI).

Someday (sooner?  later?) it would be nice to move it out of that product, which
makes a terrific IDE but sometimes has less than desireable amount of control.

- Original Message -
From: "Günter Knauf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 10:54 AM
Subject: MSI Installer


Hi,
I want to play a bit with the MSI installer; have got the httpd-win32-msi tree from 
cvs, but it seems to me that I will need
something more, perhaps a MSI-SDK from M$ or somthing like that?
Can someone please point me to the needed sources?

Thanks, Guenter.

Re: 2.0.24 ready for beta?

[William A. Rowe, Jr.]

From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 2:16 PM


> Besides, I just think it looks bad for us to constantly be swaying back
> and forth.  Oh, this release is a beta for Unix but not Win32.  Oh, this
> one is good on Win32 but only alpha-and-a-half for Unix.  

Notice that os/foo is nearly depleted :)

Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c

[William A. Rowe, Jr.]

From: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:29 PM


> trawick 01/08/23 13:29:47
> 
>   Modified:modules/mappers mod_negotiation.c
>   Log:
>   please no // in Apache code... it doesn't compile everywhere
>   
>   a note about why it is commented out would be appropriate too
>   
>   Revision  ChangesPath
>   1.73  +4 -3  httpd-2.0/modules/mappers/mod_negotiation.c
>   
>   Index: mod_negotiation.c
>   ===
>   +/*if (r->method_number == M_OPTIONS) {
>   + *return ap_send_http_options(r);
>   + *}
>   + */
>if (r->method_number != M_GET && r->method_number != M_POST) {
>return HTTP_METHOD_NOT_ALLOWED;
>}

Because I'm less than clear on the subject, so I will ask (now that you've reminded 
me)...

who's job is it to answer an M_OPTIONS request?  Every module's?  Then the mod_cgi
family is broken (this is what led me to discover that viewcvs.cgi hangs on HEAD,
maybe other cgi's are hanging, as well.)

If it's the handler's, we should review all the modules for this requirement.
If it's supposed to be the server, this code can disappear.

Re: Win32 compile breakage...

[William A. Rowe, Jr.]

Is awk installed?

- Original Message - 
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:18 PM
Subject: Win32 compile breakage...


> Dies really quick... Any thoughts as to what the problem might be? This after a fresh
> checkout of HEAD.
> 
> Configuration: libapr - Win32 Debug
> Performing Custom Build Step on .\include\apr.hw
> Created apr.h from apr.hw
> Creating Version Resource
> Error executing c:\winnt\system32\cmd.exe.
> C:\home\apache\httpd-2.0\httpd-2.0\srclib\apr\libapr.rc(1): Could not find the file 
>COFF.
> 
> Apache.exe - 1 error(s), 0 warning(s)
> 
> 
> 

Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_config.c ssl_engine_init.c

[William A. Rowe, Jr.]

From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 3:42 PM


> On 23 Aug 2001 [EMAIL PROTECTED] wrote:
> 
> > wrowe   01/08/23 12:42:44
> >
> >   Modified:modules/ssl mod_ssl.h ssl_engine_config.c ssl_engine_init.c
> >   Log:
> > Add some appropriate constness to the config
> >
> >   Revision  ChangesPath
> >   1.30  +17 -17httpd-2.0/modules/ssl/mod_ssl.h
> ...
> >   -char*szPassPhraseDialogPath;
> >   +const char  *szPassPhraseDialogPath;
> 
> This change is causing a warning about loss of constness now at
> ssl_engine_pphrase.c:535 because szPassPhraseDialogPath is passed to
> ap_strchr() which does not qualify its argument as const.  Should this
> line be backed down to char * or does something else need to be done?

Are we allowed to modify the conf after we create it?  If not, any side effects
of properly typing the config need to be dealt with.

Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 4:05 PM

> > Because I'm less than clear on the subject, so I will ask (now that you've
> > reminded me)...
> >
> > who's job is it to answer an M_OPTIONS request?  Every module's?  Then the
> > mod_cgi family is broken (this is what led me to discover that viewcvs.cgi
> > hangs on HEAD, maybe other cgi's are hanging, as well.)
> >
> > If it's the handler's, we should review all the modules for this
> > requirement. If it's supposed to be the server, this code can disappear.
> 
> Both should be able to handle it.  Basically, the default handler should do it
> if nobody else does.  But, modules should be allowed to handle M_OPTIONS
> requests.

So what you are saying, if I understand, is that a module _may_ handle M_OPTIONS,
but it _MUST_ return DECLINED if it doesn't want to deal with it, so the core
_WILL_ handle it.  Correct?

I don't think that's what we are doing everywhere, today.

Re: Location of /manual

[William A. Rowe, Jr.]

From: "Lars Eilebrecht" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 4:47 PM


> According to Martin Kraemer:
> 
> >  In other words, I propose to move /manual up one directoryy level,
> >  side by side with /icons:
> > @@ServerRoot@@/htdocs/...
> > @@ServerRoot@@/icons/...
> > @@ServerRoot@@/manual/...
> 
> This makes sense, but then we should move htdocs/error/ one
> level up, too. IMHO the server root gets cluttered up more and more
> if we do this.

I already did (no?)  /error/ was clearly along the same lines as /icon/.
But I agree with Martin, folks are more than likely to up and blow away
htdocs and start clean (with unexpected side effects.)  Least surprize.

> How about an additional directory like 'apdocs' for the manual,
> icons and error docs? It could be used by other third-party modules
> as well for storing manuals or other documents.

Hmmm... no.  /icons/ and /error/ are manditory if those parts are installed.
/manual/ is in the 'nice to have' list, and it deserves it's own spot.

If we avoided ap'docs' and made it apcontent or apfiles, well that I might 
be able to buy into.  apdocs sounds disposable.

Re: Win32 compile breakage...

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 5:42 PM


> HEAD is compiling now.  Somehow managed to get the wrong awk.exe wrapping the wrong
> gawk.exe. I must have extracted right in the middle of your last update. All seems 
>to be
> working now.

Win32 is being flakey (I missed something obvious, I'm certain).  Time for birthday 
dinner
for my daughter, I'll have this running later tonight.

Re: Win32 compile breakage...

[William A. Rowe, Jr.]

I'm on it... (just got back)... it should be fixed in an hour.
- Original Message - 
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 6:07 PM
Subject: Re: Win32 compile breakage...


> On Thu, 23 Aug 2001, William A. Rowe, Jr. wrote:
> 
> > From: "Bill Stoddard" <[EMAIL PROTECTED]>
> > Sent: Thursday, August 23, 2001 5:42 PM
> >
> >
> > > HEAD is compiling now.  Somehow managed to get the wrong awk.exe
> > > wrapping the wrong gawk.exe. I must have extracted right in the
> > > middle of your last update. All seems to be working now.
> >
> > Win32 is being flakey (I missed something obvious, I'm certain).
> > Time for birthday dinner for my daughter, I'll have this running later
> > tonight.
> 
> Uhmm... it's not just Win32.  I can't even access the default "it worked"
> page on Linux--not quite, anyway.
> 
> 
> First I tried just /
> 
> [Thu Aug 23 18:59:00 2001] [error] [client 128.143.136.188] Negotiation:
> discovered file(s) matching request: /tmp/cliff/htdocs/ (None could be
> negotiated).
> 
> Got a 404.
> 
> Then I tried /index.html ... That worked, except that the image didn't
> load.
> 
> [Thu Aug 23 18:59:59 2001] [error] [client 128.143.136.188] File does not
> exist: /tmp/cliff/htdocs/apache_pb.gif, referer:
> http://paisley.cs.virginia.edu:/index.html
> 
> So I tried /index.html.en, got a 404.
> 
> [Thu Aug 23 19:00:03 2001] [error] [client 128.143.136.188] File does not
> exist: /tmp/cliff/htdocs/index.html.en
> 
> These files _do_ exist, btw.
> 
> Tried /apache_pb.gif by hand, 404.
> 
> [Thu Aug 23 19:00:24 2001] [error] [client 128.143.136.188] File does not
> exist: /tmp/cliff/htdocs/apache_pb.gif
> 
> /cgi-bin/test-cgi doesn't work either, btw.
> 
> 
> 
> 
> --Cliff
> 
> 
> --
>Cliff Woolley
>[EMAIL PROTECTED]
>Charlottesville, VA
> 
> 
> 

Re: Letting Table store non-char data

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 6:21 PM
Subject: Re: Letting Table store non-char data


> On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > Sent: Thursday, August 23, 2001 2:37 AM
> > 
> > 
> > > On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> > > > Greg Stein wrote:
> > > >...
> > > > >Yes there is. apr_pool_userdata_set(..., r->pool)
> > > >...
> > > > Using the "userdata" functions on r->pool as a replacement for a
> > > > hash-based r->notes would be a mistake.  The interface to the userdata
> > > > in a pool is limited to "get" and "set" methods.  The API is missing
> > > > essential operations like "iterate over the set of elements in the userdata"
> > > > and "merge the userdata for a subrequest pool into the parent's r->pool."
> > > 
> > > I would posit those operations are not needed. The notes or userdata are for
> > > specific bits of information. It is not a simple collection that you can
> > > iterate over. In fact, since you can't know the values of each key, you
> > > cannot perform a useful iteration nor do a useful merge.
> > 
> > Precisely.
> > 
> > What negative consequences would that pose for subrequests?
> 
> Um. None... we have zero handling in there for any kind of munging or
> manipulation of r->notes or subreq->notes. It is all simple get/set.

Errr... then cool [I was just noting that when I was walking through the req_rec
structure.]  If someone wants a bit they can iterate, then they can tack on a
note of an apr_table_header_t, but in general, these aren't ment to be iterated.

Either you know what you are dropping in or looking for, or you don't.

+1 to dropping notes then.

Re: current cvs cannot serve static files

[William A. Rowe, Jr.]

The reason you observed this was the fact that &dir is passed to apr_filepath_root
_because_ we want that dir pointer moved forward.  The patch I applied to set
aside the caller's *dir value has fixed this part.

That isn't all, but I'm still coding.  Please (everyone) don't slap patches
willy nilly on this, I'm uncovering a ton of loose ends in our existing code
(prior to the patch set today).  If you apply a patch (like Jeff did) make it 
small, so I can undo it and see what it's covering up :)  I'm in mod_dir right
now, little wonder we have so many 'autoindex' exploits :(

Bill

- Original Message - 
From: "Doug MacEachern" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 7:55 PM
Subject: current cvs cannot serve static files


> current cvs default_handler is failing for pages that exist.  problem is
> due to ap_os_is_path_absolute() return false (in directory_walk), when the
> path is in fact absolute, so get_path_info() never happens, leaving 
> r->finfo.filetype == 0.  am i the only one seeing this?  patch below
> fixes here.
> 
> --- server/util.c   2001/08/23 19:08:19 1.109
> +++ server/util.c   2001/08/24 00:42:00
> @@ -258,8 +258,15 @@
>  AP_DECLARE(int) ap_os_is_path_absolute(apr_pool_t *p, const char *dir) 
>  {
>  const char *newpath;
> -if (apr_filepath_root(&newpath, &dir, 0, p) != APR_SUCCESS
> -|| strncmp(newpath, dir, strlen(newpath)) != 0) {
> +apr_status_t rv = apr_filepath_root(&newpath, &dir, 0, p);
> +
> +if (rv == APR_EABSOLUTE) {
> +return 1;
> +}
> +
> +if (rv != APR_SUCCESS ||
> +strncmp(newpath, dir, strlen(newpath)) != 0)
> +{
>  return 0;
>  }
>  return 1;
> 
> 
> 

Re: current cvs cannot serve static files

[William A. Rowe, Jr.]

From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 8:40 PM


> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> 
> > That isn't all, but I'm still coding.  Please (everyone) don't slap patches
> > willy nilly on this, I'm uncovering a ton of loose ends in our
> > existing code
> 
> what's good for the goose is good for the gander ;)

Agreed :)  Also, better to catch them today than in 2.0.55.

Bill

Re: Apache-1.3: question about mod_unique_id

[William A. Rowe, Jr.]

Netware, Win32, and OS2 are threaded architectures.

mod_unique_id is ugly, it made several presumptions based on the pid,
which is essentially broken on these other platforms.

If you look at the 2.0 repository, I believe we've gotten around to fixing
these broken assumptions.  But Netware, OS2 and Win32 versions 1.3 will essentially
be dead products once 2.0 is released, since the overhaul (for those platforms,
especially) is nearly total.  As of 2.0, we all use (essentially) common code,
so we all fly (or crash and burn) together.

Feel free to patch 1.3 based on 2.0 code, but realize it's heavily apr-ized,
so more would need to be done.  You have to factor the thread id into the
equation to make it even semi-workable.

Bill

- Original Message -
From: "Günter Knauf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 8:59 PM
Subject: Apache-1.3: question about mod_unique_id


Hi,
I've compiled mod_unique_id for Win32 and for Netware, and on both platforms it seems 
to work the same as with Unix, I can see a
unique id with SSI and cgi scripts; so can someone please explain why we have the 
#error about not supporting multitask OS?

Thanks, Guenter.

Re: apr-from-cvs wrong packed?

[William A. Rowe, Jr.]

Already has been.  You have .locks files since someone was committing at that
exact instant.  I suspect the next tarball won't suffer this problem, and we
will have to rm that directory from the tree, once we feel safe (2 weeks or
so) that everyone updated their trees to knock out this duplication.

Bill

- Original Message -
From: "Günter Knauf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 8:59 PM
Subject: apr-from-cvs wrong packed?


Hi,
when I extract the apr-x.tar.gz file fetched from 
http://cvs.apache.org/snapshots/apr/ I get a message about overwriting files
in the ./locks/netware dir.
Looking at http://cvs.apache.org/viewcvs.cgi/apr/locks/ only shows a 'netware' dir, 
but when I open the *.tar.gz with WinZip, I can
see that there are two dirs:
'netware' and 'NetWare', and this seems to be the problem...
can we remove one of the dirs?

Guenter.

mod_negotiation.c 1.74

[William A. Rowe, Jr.]

This introduces a bug...

Revision 1.74 / (download) - annotate - [select for diffs] , Fri Aug 24 03:04:44 2001 
UTC (79 minutes, 1 second ago) by trawick
Branch: MAIN
Changes since 1.73: +1 -1 lines
Diff to previous 1.73 (colored)
buffer .var maps to avoid asking the kernel for one byte at a
time

note that a system trace of .var map processing still shows an
extra read() after we hit EOF the first time; we could make
use of the EOF flag in APR to avoid the read() or play with
mod_negotiation

Suggested by: Marc Slemko

We now fail to read mmap var content entirely.  This is bad.
However, it is as likely as not that the apr_seek code is simply
broken on Win32 buffered files.  Please, let me know if you are 
seeing only a single variant listed for .var files if you set your 
language to something like xx for a Unix server, so I know where to 
look first in the morning.  

We actually flip between gets and read, which makes things tricky.

Thanks.

Status of the apr_filepath_merge overhaul

[William A. Rowe, Jr.]

Here is where things stand (as I go off to bed to clear my brain)...

There is something odd in mod_negotiation, beyond getting 406's on top
of errors, that I need to trace in the morning.  It is definately related to
the change to buffered code, but I'm not sure if it's mod_negotiation, or
the apr buffering that's broken.  Then I need to place the code for the
new directive I've just committed for the ForceLanguagePreference 

The win32 specific problems are fixed, we now get dir_configs again (the 
first '/' entry was not tagged d_is_absolute, so it never looked further.)

Since win32 essentially works, I suspect that unix does as well.  The big
kicker, did I code apr_filepath_merge correctly?  If so, we are good.

I will further optimize the no-pre-path-info version of directory_walk
tommorow, and assure it's solid so we can try that changeover.  All the
other window dressing today was necessary before that change stood a good
chance of working (correctly).

Finally, mod_alias needs a good optimiziation whumping which I'll attack
as soon as I can, and go back through my list of 12 potential security holes.

Boy the list is slow tonight... dunno what's up in the last hour and a half,
but my brain isn't much faster.  [Daughter's dinner was great, sorry I needed 
to disappear right after inflicting those patches today.]  Back at it tommorow.

Re: cvs commit:

[William A. Rowe, Jr.]

Exactly what it says, I committed nothing.  I was actually looking for the
backlogged mail script, and managed to fire off an empty commit message.

Bill

- Original Message - 
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 12:02 AM
Subject: Re: cvs commit: 


> On 24 Aug 2001 [EMAIL PROTECTED] wrote:
> 
> > wrowe   01/08/23 21:41:47
> >
> >   Log:
> >
> >
> 
> WTF?
> 
> --
>Cliff Woolley
>[EMAIL PROTECTED]
>Charlottesville, VA
> 
> 
> 

Re: mod_ssl.h: path removed

[William A. Rowe, Jr.]

From: "Günter Knauf" <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 6:26 AM


>Hi,
>I've just compiled mod_ssl on Win32 and I'm not happy with the removed 'openssl/'
>path because now I have to include a second path: one to ./inc32/openssl and as
>before ./inc32 self because all openssl files try to find their includes with
>./openssl prefix...(as mod_ssl.h before!)

Evidently, you don't have inc32 in your systemwide path.

The answer is to include both inc32 and inc32/openssl in our build system.  This
is preferable to some convoluted block like;

#ifdef OPENSSL_VERSION
#include 
.
.
.
.
.
.
.
.
#elif defined(SSLEAY_VERSION)
#include "ssl/foohdr.h"
.
.
.
.
.
.
.
.
#elif defined(RSA_VERSION)
#include "ssl/foohdr.h"
.
.
.
.
.
.
.
.
.

and so on (you get the picture.)

Bill

Re: mod_negotiation.c 1.74

[William A. Rowe, Jr.]

From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 8:00 AM


> Jeff Trawick <[EMAIL PROTECTED]> writes:
> 
> > "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> > 
> > > We now fail to read mmap var content entirely.  This is bad.
> > > However, it is as likely as not that the apr_seek code is simply
> > > broken on Win32 buffered files.  Please, let me know if you are 
> > > seeing only a single variant listed for .var files if you set your 
> > > language to something like xx for a Unix server, so I know where to 
> > > look first in the morning.  
> > > 
> > > We actually flip between gets and read, which makes things tricky.
> > 
> > The problem seems to be that ungetc doesn't work on buffered files.
> > And yet the ungetc operation is usually needed by program logic that
> > needs buffering.
> 
> Oops, this was a Unix statement (now out-of-date :) ).  I have no idea
> why mod_negotiation is failing on Win32.  testfile.exe just ran fine
> for me on Win98.  I don't have a way to run Apache on Win32, so no
> guesses on the failure other than that the problem is most likely in
> srclib/file_io/win32/*.c :)

I'm certain the bug is also in the ungetc/seek buffering code.

While we are on mod_negotiation.c, our logic to slam down a mod_include
request on the second recursion breaks the server horribly.  Just try the
error documents right now, via indirection.  We get a 506 (variant also
negotiates) which we shouldn't be seeing with a 1:n match in a .var file.

Bill

Re: is apache building properly for anybody on Darwin?

[William A. Rowe, Jr.]

From: "Greg Ames" <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 9:12 AM


> Jeff Trawick wrote:
> > 
> > I just tried it for the first time in a few days and the installed
> > httpd won't load:
> > 
> > "dyld: /Users/trawick/regress/install/bin/regresshttpd can't open
> > library: .libs/libaprutil.dylib (No such file or directory, errno = 2)"
> > 
> > I haven't looked into it at all (and I'm in no hurry to either :) ).
> > 
> >
> 
> weird stuff is happening on FreeBSD (daedalus) as well.  
> 
> [gregames@daedalus httpd-2_0_25dev]$ ls -l ../httpd-2_0_24/httpd
> -rwxr-xr-x  1 root  gregames  1506967 Aug 19 07:24 ../httpd-2_0_24/httpd
> 
> [gregames@daedalus httpd-2_0_25dev]$ ls -l httpd
> -rwxr-xr-x  1 gregames  gregames  5147 Aug 23 13:54 httpd
> 
> h, that's quite a drop in size

That looks right ... as the difference between a static and dynamic build.

Re: Win32 compile breakage...

[William A. Rowe, Jr.]

From: "jlwpc1" <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 1:05 PM
>
>> Is awk installed?
>> 
>
>>Somehow managed 
>>to get the wrong awk.exe wrapping the wrong
>>gawk.exe. 
>
>Try Windows Script Host ( WSH ),
>(always there, always ready), since
>Apache now fully supports Windows
>OS (and IE) tools!  :)

Since exactly one person (I) responded to your suggestion to check their
machine (to see how widely installed cscript is) I presume there is zero
interest in your suggestion (1-1=0, for reasonably typical values of 1).

http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp?sd=MSDN

FileName "cscript.exe" tells me

cscript.exe  5.1.0.4615  More Information  Microsoft (r) Console Based Script Host  

No distribution information provided, presuming a component of the WSH download

cscript.exe  5.1.0.4411  More Information  Microsoft (r) Console Based Script Host  

Distributed with  Windows 2000 BETA RC2  9/9/1999 

cscript.exe  5.0.531.7   More Information  Console Based Scripting Host  

No distribution information provided, presuming a component of the WSH download

And Apache runs under Win32, but should be buildable with any toolset, provided
 introduces the flexiblity to build under BCC/Watcom/GNU etc.  CScript
(plus every component we then trust to be available and properly versioned, a rarity
from the MS com development team) puts us in the other direction, with the exception
of authoring some additional parts (the MSI installer, for example) where there is no
alternative.

I guess that ends that discussion.  Try awk, 135kb, runs anywhere.  Plus, it's the only
part of the Win32 msi package that always works for everyone.

Re: Ryan's comments about split_and_pass_pretag_buckets.

[William A. Rowe, Jr.]

- Original Message - 
From: "Paul J. Reder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 6:02 PM
Subject: Re: Ryan's comments about split_and_pass_pretag_buckets.


> Ryan,
> 
> I am in the process of digging myself out of a weeks worth of lost mail,
> but I am working to address the issues with my commited patch to mod_cgi,
> mod_cgid, and mod_include.
> 
> Unless you have another preference, I will be moving the code to a common
> location in util_filter.c.

Huh?  util_script exists soley to support the modules you just mentioned.

Unless, as rbb points out, that the facilities will never be used outside
of mod_include

Re: cvs commit: httpd-2.0/include http_core.h

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Friday, August 24, 2001 4:51 PM


> On Fri, Aug 24, 2001 at 04:24:35PM -0500, William A. Rowe, Jr. wrote:
> >...
> > I'm not approaching this again until I've slept on it.  I have the patch
> > essentially finished, adding a per-'dir' (proxy location, really) pattern
> > of p, with a isregex flag of r.  That's about as complicated as it gets.
> 
> I'm not sure that I follow what the pattern thing is all about.

Regex expressions, instead of strcmp matching.  (E.g. )

> >...
> > There will be no more 'faux' filenames.  It's either an absolute path, or
> > undefined (and irrelevant.)  A few modules will get to deal with in anyways
> > (such as mod_mime.)
> > 
> > I'll start tommorow and wrap up tommorow, so everyone can take a look at what
> > else this impacts.  But getting rid of 'specials' is the only way to clean out
> > directory_walk of all it's very heavy cruft.
> 
> Note that r->filename and friends (finfo, canonical_filename, etc) are all
> related to the filesystem. As such, they are all completely bogus when
> you're talking about purely virtual resources (such as /server-status or
> content coming from a database). Thus, they should not be part of the
> request_rec, but instead part of a private structure to something like
> mod_filesystem. That mod_filesystem would implement the various translation
> and other fs-related items that occur.

No argument here ;)  This should work out pretty darned well, but I would argue
everyone needs to be able to access the r->filename if their module works with
'files'.  That doesn't mean every request needs an fs_request_rec member :)

> And no... I'm not suggesting this happen any time soon :-) But it will one
> day, if I can figure out how to tackle it and can set aside the time.

Re: ErrorDocuments?

[William A. Rowe, Jr.]

I think that's the mod_include recursion tests that doug committed.  We actually
_do_ want to recurse that way (in fact, the subreq file == the request file, only
the subreq sends a much smaller file bucket of just one body from the file.)

Partly, it should be solved by mod_neotiation assuring a language will be served,
which is the code I was hacking when I sidestepped back to finish the dir_walk
and overall path handling.  I'll step back up and wrap it up by Monday, and figure
how we can eliminate the 506 for error pages.

Bill

- Original Message - 
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2001 1:48 AM
Subject: ErrorDocuments?


> Go to any bogus URL (i.e. foo/) with the default config and you get:
> 
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /foo was not found on this server.
> Additionally, a 506 Variant Also Negotiates
> error was encountered while trying to use an ErrorDocument to handle the
> request.
> 
> 
> What's this 506 error doing here?  I'm sorry but I didn't really follow
> all of the variant ErrorDocument threads.  =-)  -- justin
> 
> 

Re: pools and buckets/brigades, WAS: RE: Review of possible replacement for pools

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2001 1:40 PM


> > I have a problem with the original question though.  I don't understand why
> > anybody is trying to state that if people want to improve the pools code, they
> > shouldn't, because we use malloc in one place in the code.  People are
> > free to work on whatever they want.
> 
> I am not being philosophical. Sure, people can spend their time doing whatever they 
>want.
> I assume open source developers like to see others benefit from their labor. If the 
>goal
> is to improve the performance of the http server, (remember this was posted to 
>dev@httpd
> and that is why I reference the http server), they are wasting their time trying to
> improve the pool code. There are clearly more serious memory allocation problems to 
>solve
> first.

Then scratch that itch, Bill, instead of moaning about it.

> Gotta run. Party on...

My point exactly ;)

Re: cvs commit: httpd-2.0/server request.c Makefile.in

[William A. Rowe, Jr.]

> rbb 01/03/04 20:43:56
> 
>   Modified:.libhttpd.dsp
>include  http_request.h
>modules/http http_protocol.c http_request.c
>server   Makefile.in
>   Added:   server   request.c
>   Log:
>   Another chunk of code from http to core.  This should continue to build
>   on all platforms.  The next job is to shuffle functions back and forth
>   so that the server builds without mod_http.
>   
>   1.25  +4 -0  httpd-2.0/include/http_request.h
>   
>   Index: http_request.h
>   ===
>   RCS file: /home/cvs/httpd-2.0/include/http_request.h,v
>   retrieving revision 1.24
>   retrieving revision 1.25
>   diff -u -d -b -w -u -r1.24 -r1.25
>   --- http_request.h 2001/02/16 04:26:31 1.24
>   +++ http_request.h 2001/03/05 04:43:55 1.25
>   @@ -304,6 +304,10 @@
> */
>AP_DECLARE_HOOK(void,insert_filter,(request_rec *r))
>
>   +AP_DECLARE(int) directory_walk(request_rec *r);
>   +AP_DECLARE(int) location_walk(request_rec *r);
>   +AP_DECLARE(int) file_walk(request_rec *r);
>   +
>#ifdef __cplusplus
>}
>#endif

You can't do this without namespace protection.  Patch forthcoming.

Re: cvs commit: httpd-2.0/modules/filters mod_include.c

[William A. Rowe, Jr.]

From: "Joshua Slive" <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2001 9:23 PM
> 
> Before I go back and put back all the stuff I took out of the docs on
> mod_include handlers (;-) could you clarify this a little for me.
> 
> 1. True/False:  Using the handler is perfectly equivalent to using the
> filter except in the case where more than one filter or handler is in use
> or a content-type other than text/html is being filtered.  The
> server-parsed handler cannot be used when another handler is in use for
> the same file (eg. cgi-script).  As well, the server-parsed handler will
> always run first, so if you wish the INCLUDES filter to run after another
> filter, you should explictly specify the filter chain using SetFilter.
> Finally, the server-parsed filter will always output HTML, whereas the
> INCLUDES filter can process any file type and will not change the
> content-type.

Actually, they are very different.  I don't know which we will endorse.
I'd expect performance testing to answer the question...

> 2. What is the "recommended" way of using mod_include?  SetFilter is more
> flexible, but the  thing makes it hard to use and slows down
> the directory-walk.

_Much_ slower with subrequests (that would otherwise reuse the last dir_walk!)

> 3. If you are going to add back the magic-mime-type, please let me know so
> I don't have to re-re-revise the docs.

Dunno those plans

Re:

[William A. Rowe, Jr.]

- Original Message - 
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2001 10:01 PM
Subject: 


> ... passes the config parsing with flying colors, even when it's meaningless.
> 
> Is there a reason we are allowing unrecognized/unparsed blocks into the config?  
> I would expect we would want to error out.
> 
> I discovered this with my  patch, when I forgot
> to load the proxy module.  We wouldn't accept an unrecognized directive,
> why accept an unrecognized block tag?
> 
> Bill
> 
> 

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 9:43 PM


> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Sunday, August 26, 2001 4:04 AM
> 
> 
> > On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote:
> > > wrowe   01/08/25 16:43:19
> > > 
> > >   Modified:.CHANGES
> > >include  http_request.h
> > >modules/http http_core.c http_protocol.c http_request.c
> > > mod_core.h
> > >server   core.c request.c
> > >   Log:
> > > Introduce the map_to_storage hook, which allows modules to bypass
> > > the directory_walk and file_walk for non-file requests.  TRACE
> > 
> > How is this different from the translate_name hook? Your new hook and the
> > translate_name are both about translating URLs into the backend storage.

Going into more gorey detail (I was wrong, translate name does run the first.)

translate_name

  core  /foo/bar maps to c:/docroot/foo/bar

  alias /foo/bar is c:/some/bar

  [it would go no further, nothing else in translate name gets a chance.]

map_to_storage

  proxy?  we aught to proxy_walk instead.

  TRACE?  hey, we need to go no futher

  core:   well what are the  sections for c:/some/bar?

These are two different phases of the same part of the server.  Before, nobody
could circumvent  processing.  Now we allow it if the module has a very
clear understanding of what they are doing.  I don't like the name map_to_storage,
and wasn't kidding when I suggested the walkers_run hook (as in, ap_run_walkers_run :)
because it actually describes what we are doing.  The fact that TRACE ends up lodged
in there has more to do with the fact that proxy MUST override the default TRACE
behavior, or it can't pass traces to the proxied server.

I'm taking names for the map_to_storage handler, if anyone has a better suggestion.
Some possibilities are parse_dir_config, fixup_dir_config, whatever.

Bill

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 11:48 AM


> > On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote:
> > > wrowe   01/08/25 16:43:19
> > > 
> > >   Modified:.CHANGES
> > >include  http_request.h
> > >modules/http http_core.c http_protocol.c http_request.c
> > > mod_core.h
> > >server   core.c request.c
> > >   Log:
> > > Introduce the map_to_storage hook, which allows modules to bypass
> > > the directory_walk and file_walk for non-file requests.  TRACE
> > 
> > How is this different from the translate_name hook? Your new hook and the
> > translate_name are both about translating URLs into the backend storage.
> > 
> > Why was this new one added? (did I miss some discussion somewhere?) And if
> > so, then why does translate_name stick around?
> 
> Sounds similar to the quick_handler hook as well.

It does?  Then you need to find a clue.  quick_handler should have been axed
from the outset, and now that this handler allows a non-filesystem request to
be handled properly, it really should be gone.

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 4:04 AM


> On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote:
> > wrowe   01/08/25 16:43:19
> > 
> >   Modified:.CHANGES
> >include  http_request.h
> >modules/http http_core.c http_protocol.c http_request.c
> > mod_core.h
> >server   core.c request.c
> >   Log:
> > Introduce the map_to_storage hook, which allows modules to bypass
> > the directory_walk and file_walk for non-file requests.  TRACE
> 
> How is this different from the translate_name hook? Your new hook and the
> translate_name are both about translating URLs into the backend storage.
> 
> Why was this new one added? (did I miss some discussion somewhere?) And if
> so, then why does translate_name stick around?

The original idea for the hook name was walkers (as in ap_run_walkers()).
map_to_storage actually validates that the translated name is serveable,
and sets up any storage specific per_dir_config values.  It was also going
to pick up the downgrade http protocol, but that doesn't make sense in this
hook.  I'll move that aspect to the bottom of the translate_name phase.

Perhaps this should be get_storage_dir_config or something like that.
Note it is run first, instead of run all (as the translate_name hook is),
so that _one_ module can assume ownership and pick back up the request
after the authz/authn phases.

This hook has enormous reprecussions on avoiding directory walks and file walks
that we have all complained so long about.  The patches today to mod_proxy
(adding a proxy_walk phase, and skipping the old cruft) illustrate this.  Now
that proxy and directory sections are listed seperately, we save a ton of tests
in both given a complex server configuration.  dir walks  sections, and
proxy walks  sections, period.

The last remaining hurdle outside of dir/file walking is the duplicate 
walk we perform.  I'm preparing a patch to do this walk once, and as long as the
r->uri is unchanged, we continue to merge the same 'preconstructed' location walk
every time we repeat that step.

I want to lock down the default handler as well, to error 500 if we didn't call
dir_walk/file_walk because a badly written module circumvented the core 
map_to_storage hook fn.  After that, I believe we will be as good as can be, with
some major cleanup needed to subreq/internal_internal_redirect handling.

Bill

Re: Debugging in Windows

[William A. Rowe, Jr.]

From: "Amit Athavale" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 12:10 AM


> Hello,
> In Win32 environment there are two procees run by apache. One is main proceess 
> and other is child one. But this makes debugging difficult. As we start Dev studio 
> debugger on main procees. 

Unless you attach-to-process, in which case, you run out to the task manager, change
the view to display the threads column, choose the one with 50+ instead of only 3 
threads,
and attach to that process id.

Much easier, simply edit the project settings, debug tab, and change the arguments!
-D ONE_PROCESS for 2.0 or if you are playing in 1.3, use -X.  You need to change those
anyway to point to the _installed_ Apache.exe location, not the build tree location.

> Is there any way to start apache in single process. Other than changing following 
> code :: static int one_process = 1;

Yes, the argument.

> Can we have some preprocessor definitions to make it one-process

Better, change the debug settings.

and if you are debugging shared modules, change the debug setting to include the .so
you are developing (at it's target location in /Apache/modules/... not in the build
tree) in the Additional DLLs tab.  That way, it preserves your breakpoints, even though
it won't get into that module until after the module is loaded.

Happy debugging :)

Re: location walk before directory walk

[William A. Rowe, Jr.]

From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 1:54 AM


> Just out of curiosity, would it be easier if, for 2.0, we fixed the
> original bogosity of location walk by running it first, before directory
> walk, and simply forbid its use within .htaccess?  That would eliminate
> most of the issues regarding wasted time spent checking directories for
> things that are only virtual namespaces.

I think the patches to date accomplish that.

If you have a virtual namespace, and register a map_to_storage hook as
HOOK_MIDDLE, and it simply returns OK, then the second Location walk won't
even be walked again.

Bill

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Barrie Slaymaker" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 3:22 AM


> On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
> >core_a = ap_get_module_config(a->elt, &core_module);
> >core_b = ap_get_module_config(b->elt, &core_module);
> >   -if (IS_SPECIAL(core_a)) {
> >   - if (!IS_SPECIAL(core_b)) {
> >   - return 1;
> >   - }
> >   +
> >   +if (core_a->r < core_b->r) {
> >   +return -1;
> >}
> >   -else if (IS_SPECIAL(core_b)) {
> >   - return -1;
> >   +else if (core_a->r > core_b->r) {
> >   +return 1;
> >}
> 
> Does this bit mean that regex-based sections won't run in config-file
> order, but in order of their positions in the heap?

They always have run in this order,

  1. Non regex expressions first, then all regex'es
  2. By the number of components (so '/', then '/foo', then '/foo/bar')
  3. By their order in the configuration file.

The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in  sections.  The proxy: entries can now be configured
with  sections.  And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want 
them sorted by any critera.)

Bill

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Barrie Slaymaker" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:22 AM


> On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
> > From: "Barrie Slaymaker" <[EMAIL PROTECTED]>
> > Sent: Monday, August 27, 2001 3:22 AM
> > 
> > 
> > > On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
> > > >core_a = ap_get_module_config(a->elt, &core_module);
> > > >core_b = ap_get_module_config(b->elt, &core_module);
> > > >   -if (IS_SPECIAL(core_a)) {
> > > >   - if (!IS_SPECIAL(core_b)) {
> > > >   - return 1;
> > > >   - }
> > > >   +
> > > >   +if (core_a->r < core_b->r) {
> > > >   +return -1;
> > > >}
> > > >   -else if (IS_SPECIAL(core_b)) {
> > > >   - return -1;
> > > >   +else if (core_a->r > core_b->r) {
> > > >   +return 1;
> > > >}
> > > 
> > > Does this bit mean that regex-based sections won't run in config-file
> > > order, but in order of their positions in the heap?
> > 
> > They always have run in this order,
> > 
> >   1. Non regex expressions first, then all regex'es
> >   2. By the number of components (so '/', then '/foo', then '/foo/bar')
> >   3. By their order in the configuration file.
> 
> #3 is why I responded.  This patch seems to change that nice behavior;
> like regexes are sorted by their addresses (the value of core_{a,b}->r)
> rather than their position (core_{a,b}->orig_index).

OUTCH!  It does, thank you!


if ((core_a->r != NULL) < (core_b->r != NULL)) {
return -1;
}
else if ((core_a->r != NULL) > (core_b->r != NULL)) {
return 1;
}

does that look better :-?  I'll commit as soon as someone tells me sanity (or at least
my abuse of pointers as bools) is cured :)

Bill

> > The only thing this patch changes is that 'specials' (such as proxy: entries)
> > cannot be in  sections.  The proxy: entries can now be configured
> > with  sections.  And my patch to run Proxy entries doesn't sort them
> > at all (I have posted the question to the modproxy-dev list, if we even want 
> > them sorted by any critera.)
> 
> Yup, I like the  
> As far as sorting, it would be nice for everyone's sanity if
> <(Directory|Location|Proxy)(Match)? sections were sorted using as
> similar a logic as possible.  Given the number of incremental directives
> that are starting to crop up, sort order is going to be very important
> to config stability.  By incremental directives, I mean directives where
> previous settings are modified by directives occuring in later directory
> sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
> and like external modules do (see AxKit's directives for a lot of
> these).
> 
> Just the ramblings of someone who's had to explain the current state of
> affairs and watch the heads shaking...
> 
> - Barrie
> 
> P.S. I also like the suggestion that went by to make the first
> ap_location_walk "stick" and do away with the second.  It's much more
> intuitive to me: URIs get run through the  ( the duplicate ap_location_walk()s should be much less now that  sections exist.
> 

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:41 AM


> > map_to_storage is definitely not the same as quick_handler. But
> > quick_handler does have a use so it stays in.
> 
> Actually, they are closer than you might think.  quick_handler's purpose is to allow
> requests to be served as quickly as possible.  It skips a lot of phases of the
> request to accomplish that.  If map_to_storage is tweaked a bit, it can accomplish
> the same thing.

It's not going to be tweaked (you security sloths, you :)  We need to look at each of
the hook phases, and figure out how a module can selectively bypass that hook, when
it should, and why.  I'll probably start a paper detailing how the current Apache 
system
exposes hooks, and what's the harm in using/bypassing those hooks.

Quick_handler bypasses everything.  We ignore the client's headers, the server's 
configuration, everything.  Frankly, quick_handler is not Apache, and anyone who 
writes 
a quick_handler hack and calls it a module for 'Apache' is full of sh*t.  Powered by 
the 
Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.)

> Basically, the map_to_storage function that succeeds would tell the server how many
> of the hooks that follow map_to_storage that it should skip before the handler phase.

No... I thought long and hard about that, and I dislike it.  It's full of opportunities
to mess up security and bypass things you didn't expect (in v. 2.1 or whenever.)

hook_to_storage (named wrong, we agree) is the trap to walk a set of dir_config's that 
are
customized for the module.  50% of the modules serve files, so they _don't_ hook this 
call.

40% of the modules invent content in a "yes or no" sort of way.  They are generally 
driven
by the  block, so that block can contain their access restrictions.  They 
don't
want us to hook up any extra dir_config's, so they may hook this call and just return 
OK.

10% of the modules (e.g. proxy, perhaps a database-driven content store) don't have 
'files'
in the traditional sense, but they want a tree mapping of restrictions, and it won't
correspond to our  sections in a 1:1 manner.  For those modules, 
they
can hook and replace dir_walk/file_walk with their own (e.g. proxy_walk.)

> This has a couple of advantages over quick_handler, the first one being that it
> is more general, and the second that it means we go back to having one location that
> data is sent to the network.

Yes - it's definately a design decision that an author needs to be aware of.  We aren't
working well enough with too many modules as it is (take mod_autoindex/negotation/mime
security reports, or tomcat security reports.)  We don't want module authors to suffer
from a slow model.  But we don't want them wandering too far out of the fold, until 
they
fall in the pit that so many modules have landed in.

> If that change is made to map_to_storage, then I would be with OtherBill, and
> suggest that quick_handler should be removed.

I'm about to suggest that as well, but I don't think we can do so until we optimize our
whole server.

That is, I just optimized the two-pass  parsing.  Unless the URI is remapped
(a significant context change that requires rewalking the location), or we have been 
mapped
to a virtual server with a different set of locations (they probably wern't inherited 
from
the base server), then we will do zero or one directory merges.  Zero merges if no 
module
modified the per_dir_config since we left it (no dir/file/proxy walk), or one merge if 
we
see someone reset per_dir_config, so we will overlay it.

Almost every hook can be a bit more optimized this way.  I'm most concerned about 
subreq
and internal redirect mechansims, and will continue to work to assure 1. they do the 
same
thing, even in different contexts, and 2. they rely on the original request as much as
possible to drop cpu/filesystem load.

An example ... dir_walk can do the same thing as location_walk does.  If we already 
walked
the first 3 directory elements, and come back with a subreq for a subdir, why 
duplicate the
work?  We have some great opportunities here for cleaner, smaller and faster code.  
Then
I'll suggest dropping quick_handler, and have a document to back up my position :)

Bill

Re: location walk before directory walk

[William A. Rowe, Jr.]

From: "Joshua Slive" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:57 AM


> On Mon, 27 Aug 2001, Ryan Bloom wrote:
> 
> > On Monday 27 August 2001 05:54, Bill Stoddard wrote:
> > > > From: "Roy T. Fielding" <[EMAIL PROTECTED]>
> > > > Sent: Monday, August 27, 2001 1:54 AM
> > > >
> > > > > Just out of curiosity, would it be easier if, for 2.0, we fixed the
> > > > > original bogosity of location walk by running it first, before
> > > > > directory walk, and simply forbid its use within .htaccess?  That would
> > > > > eliminate most of the issues regarding wasted time spent checking
> > > > > directories for things that are only virtual namespaces.
> >
> > Just a question, but what if you are using .htaccess files to partition things
> > up for virtual hosts?  For example, I am running a server and both Roy and
> > Bill have sites on it.  Since I am a control freak, I refuse to give either access
> > to httpd.conf, but because I am also lazy, I have allowed both to use
> > .htaccess files.  In that case, don't people need to be able to put 
> > directives inside of .htaccess files?
> 
> Either I am missing something, or there is an error in the docs; the 1.3
> docs state that  is not allowed in .htaccess.

Correct.  The array of  directives is stored in the virtual server.

Changes to the virtual host, or the uri itself, both necessitate rewalking the
 list.  That's why location_walk is invoked twice.

Re: [PATCH] Apache 1.3.21-dev for NetWare builds (5)

[William A. Rowe, Jr.]

From: "Pavel Novy" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 9:08 AM


> I suggest to fix the problem as described (patch attached), even if it will be 
>considered as CodeWarrior's bug (and fixed, then)
by Metrowerks or not. I've detailedly analyzed the issue and I see no way how to stay 
backwardly compatible with this issue, so all
binaries for NetWare platform (Apache core+modules from CVS sources and all "3rd 
party" external modules produced with CW) should be
re-built after the fix (if it will be commited) - it will not be possible to mix new 
NLMs with older Apache core or modules.
>
> I have tested the fix with CW 5.3 and gcc 2.95.3 and it seems that alignment of 
>problematic structures is the same (it differs
from current status quo, of course). The change in the source file shared on all 
platforms is requested, so verification on these
ones will be needed. I don't expect problems (no change in alignment) on platforms 
where the GNU stuff is used (gcc). Thanks.

Pavel,

  I'm sorry, I cannot see this code change for the 1.3 generation.  I sympathize that 
the
implementors on the Netware platform refuse to see eye to eye (or even attempt to bring
some sort of compatiblity options to the table.)  And the unsigned char solution is 
very
slow, compared to integer manipulation, so I'm not sure we would choose that anyways.

  Please bring this discussion to Apache 2.0.  I know Brad Nicholes and company at 
Novell
are working hard to support Apache 2.0.  This implementation will be a far more secure 
and
stable platform than the 1.3 hybrid/threaded implementations (win32/os2/netware etc.)

  If we direct our energies at solving the problem there, and we can agree on a 
mechansim,
I see this issue being resolved in Apache 2.0.

Bill








> --- util_uri.h.orig Mon Feb 26 16:49:32 2001
> +++ util_uri.h Mon Aug 27 15:44:41 2001
> @@ -106,10 +106,10 @@
>
>  unsigned short port; /* The port number, numeric, valid only if port_str != 
>NULL */
>
> -unsigned is_initialized:1;
> +unsigned char is_initialized:1;
>
> -unsigned dns_looked_up:1;
> -unsigned dns_resolved:1;
> +unsigned char dns_looked_up:1;
> +unsigned char dns_resolved:1;
>
>  } uri_components;
>
>

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 10:54 AM


> > > > map_to_storage is definitely not the same as quick_handler. But
> > > > quick_handler does have a use so it stays in.
> > >
> > > Actually, they are closer than you might think.  quick_handler's purpose is to 
>allow
> > > requests to be served as quickly as possible.  It skips a lot of phases of the
> > > request to accomplish that.  If map_to_storage is tweaked a bit, it can 
>accomplish
> > > the same thing.
> >
> > Quick_handler bypasses everything.  We ignore the client's headers, the server's
> > configuration, everything.  Frankly, quick_handler is not Apache, and anyone who 
>writes
> > a quick_handler hack and calls it a module for 'Apache' is full of sh*t.  Powered 
>by the
> > Apr/Apache MPM/load manager is more like it (that isn't badness, that's just 
>reality.)
> 
> So tell us how you -really- feel :-)

Let me fine-tune my statement.  Modules that use quick_handler bypass the _user's_ 
expectations,
and our documented behavior.  If this is ok for a given module, and is well 
documented, then fine.

I feel that nothing frustrates me more, personally, than to follow docs and observe a 
different
result than was doumented.  That's why I turned Greg to the / 
combinations
for DAV, since they have odd side-effects.  

> I am looking at the map_to_storage hook to see how it works. Stay tuned.  The
> quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an 
>-Apache-
> module. It is a specialized hook to serve a specialized purpose: serving web pages 
>as fast
> as possible from a user space resident cache. And it can be used without 
>compromising the
> security of the server.

The best example is loading the mod_proxy/proxy_http combination.  I have to say that 
the patch
to mod_proxy was about as clear as I've ever written.  It will give you a terrific 
feel for what 
can be done :)

>From an optimization perspective, see the  patch from last night, it shows 
>what you
can do with pre-cached per_dir_config's, you would just need to use config wide pools 
and voila,
mod_file_cache can have preconstructed per_dir_configs too.  I'll be modifying 
 to
also observe any preconstruction, so all internal_internal_redirect and subreq 
entities can go
back through directory_walk without consuming significant CPU.

Bill

r->assbackwards

[William A. Rowe, Jr.]

Folks,

  I have a two simple questions.  One; does assbackwards simply refer to HTTP/0.9?

  Two; why are we trying to support HTTP/0.9 in the year 2001?  How many pre HTTP/1.0
clients are out there to support?

  I know the proxy team would like to remove some XXX deal with r->assbackwards 
comments
in their code :)

Bill

Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c

[William A. Rowe, Jr.]

From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 3:42 PM


> [EMAIL PROTECTED] writes:
> 
> > trawick 01/08/24 04:35:58
> > 
> >   Modified:modules/mappers mod_negotiation.c
> >   Log:
> >   temporarily back out the buffering of .var files while folks
> >   have a chance to get APR ungetc working properly on buffered
> >   files
> 
> Is this working on Win32 yet?  
> 
> >   --- mod_negotiation.c 2001/08/24 10:40:04 1.76
> >   +++ mod_negotiation.c 2001/08/24 11:35:58 1.77
> >   @@ -889,7 +889,7 @@
> >/* We are not using multiviews */
> >neg->count_multiviews_variants = 0;
> >
> >   -if ((status = apr_file_open(map, rr->filename, APR_READ | APR_BUFFERED,
> >   +if ((status = apr_file_open(map, rr->filename, APR_READ /* | APR_BUFFERED 
>*/,

Probably not yet :(  That is, buffering may work, but seek'ing within a buffered
apr_file_t probably doesn't.

Bill

Re: location walk before directory walk

[William A. Rowe, Jr.]

From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 4:23 PM


> > Just a question, but what if you are using .htaccess files to partition things
> > up for virtual hosts?  For example, I am running a server and both Roy and
> > Bill have sites on it.  Since I am a control freak, I refuse to give either
> > access
> > to httpd.conf, but because I am also lazy, I have allowed both to use
> > .htaccess files.  In that case, don't people need to be able to put
> >  directives inside of .htaccess files?
> 
> I would think that the appropriate thing to do in that situation is
> shoot the admin.  [Or just tell them to use the config option that
> separates httpd.conf into a tree of separately owned directories.]

I still believe that there are fundemental per-vhost issues with eliminating
the  walk following whatever 'walkers' are configured by a given
module/storage scheme.

As a 'permission granted', there really is nothing wrong with using 
blocks.  Restricting permissions with  is futile, of course.

Take this example

DocumentRoot "/userland/web/sites"



Allow from all
Deny from none



Alias /DAVSpace/ "/userland/web/sites/"


Dav On
Order deny,allow
Allow from localhost
Require valid-user
Satisfy Any



This configuration would be impossible without the trailing  config.

Note we don't walk that config any more.  Since the request for /DAVSpace/myfile
was satisfied on the first try, the URI didn't change during the directory walk,
the premerged location will be reused.  That's the benefit of my patch last night.

Bill

Re: cvs commit: httpd-2.0/server core.c request.c

[William A. Rowe, Jr.]

From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 4:45 PM


> A quick_handler operates the way that a Web server is supposed to operate.
> I should be able to add a hook that detects a Code Red request and immediately
> close the connection with as little server overhead as possible.  Normally
> I would do that with a custom change to the HTTP parser, but it makes more
> sense to do it as a hook with quick_handler.

I'd really like to see a quick_handler patch that has the socket drop that
connection entirely, waiting in SYN for the ACK response :)

Bill

Re: Fw: HTTP response problem on 2.0.24

[William A. Rowe, Jr.]

From: "Jerry Baker" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 4:55 PM


> "William A. Rowe, Jr." wrote:
> > 
> > > This is the reason that the huge number of folks offering their 'binaries' irks
> > > me.
> 
> Here's the problem: On *nix machines you can get a compiler for free and
> figure out how to use it. If you can figure out how to use it, then
> you're probably smart enough to know what you're getting into by
> building an alpha quality product. With the Windows platform the
> compiler costs a minimum of $100+. That is out of the range for many
> qualified persons to afford (I couldn't even afford it now). It is also
> out of the range of persons who primarily run *nix but do some testing
> on Windows. That is the reason for my binaries. It is not to let anyone
> and everyone download Apache. If I knew of a way to stop unqualified
> individuals from downloading it I would do it. Do you know any way?

No, I know of no way to prequalify users.  Heck, even the big warning "Windows 95
users READ THIS FIRST" warning at www.apache.org:/dist/httpd/binaries/dist still
allows half a dozen induhviduals download without grabbing a good WinSock (that
always scares me.  Code Red?  Little wonder.)

Heck, I have an install package (considerably improved) nearly finished for 2.0.
I built binaries from .16 through .24, but we've found real show stoppers each
time on the Win32 branch.

When I replied to this fellow, I really believe that .25 can be beta quality by
the end of this week.  Optimistic?  Perhaps.  But it still isn't going to be
ready for Windows 9x/ME.  Will probably throw the toggle to discriminate against
installation on pre-NT machines to be on the safe side.  Once we have some idea
that it actually runs, and we've crippled the features in APR that will hurt
the server, then we are ready for 9x/ME binaries.

Once some folks spend some real time testing on 9x (these are developers, mind
you, with compilers) and we have the kinks worked out, then unleash it on the
world.  I know there are a half dozen of you out there.  If I had 80 more hours
a week, I'd be chipping in too (and will, once my plate is somewhat cleared and
NT is actually beta ready.)  I will at least promise to do my best to get the
code fixes committed that Win9x folk offer up.

But you can't productively solve bugs without a compiler and a debugger.  
Apache 2.0 on Win9x isn't ready for a farm team, never mind the majors.  As soon 
as someone assures me otherwise (I know Mladen started some code, of which I need 
to get to committing sooner) then we will kick some binaries out the door.

> PS - Sorry for the OT spam, but I could not find these posts on my NNTP
> server.

No fear... it's not OT.  

Fw: HTTP response problem on 2.0.24

[William A. Rowe, Jr.]

Just to file this away where I won't loose it.  Unfortuatnely, with buckets, it will
be a danged site difficult to find the win9x invalid operation.

Sort of cute that we bubble up rv's instead of http result codes :(

Bill

- Original Message - 
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Newsgroups: comp.infosystems.www.servers.ms-windows
Sent: Monday, August 27, 2001 4:00 PM
Subject: Re: HTTP response problem on 2.0.24


> It's a network error (32045 - 22000 is 10045, winsock error WSAEOPNOTSUPP).
> 
> Now that's odd.  But as everything on the ASF site indicates, it really doesn't
> work on Windows 9x (or ME) yet.  You were warned.
> 
> This is the reason that the huge number of folks offering their 'binaries' irks
> me.  Please don't any support on this yet.  A beta for Windows NT is in the works
> (likely to be 2.0.25) and a beta on 9x will follow the next month.
> 
> But as the group has always indicated, if you can't compile Apache yourself, you
> aren't ready for 2.0 (or, 2.0 isn't ready for you :)
> 
> Bill
> 
> 
> 
> "Michael Maclean" <[EMAIL PROTECTED]> wrote in message 
>news:9mebgr$1e261$[EMAIL PROTECTED]...
> > Hi,
> > Apologies if this is a blindingly obvious problem ;o)
> >
> > I downloaded the Windows binary of Apache 2.0.24 from Jerry Baker's site and
> > installed it onto my 98 First Edition machine, and all seems to be fine. I
> > changed all the @@ lines in httpd.conf to valid values and started the
> > server, and it seemed to work fine. I then changed it to run on port 8080 to
> > avoid messing with my existing 1.3.20 setup. I then started running through
> > the manual pages in the htdocs folder via http://localhost:8080, until I
> > tries to access the /manual/misc/FAQ.html page. When I did this, it came
> > back with a page titled "200 OK" and saying "OK" then "The server
> > encountered an internal error or misconfiguration..." like you get with a
> > 500 error. It only seems to happen with certain pages:
> > /manual/misc/client_block_api.html seems to work fine.
> >
> > Nothing appears in the error log when this happens, but the access log looks
> > like this:
> > 127.0.0.1 - - [27/Aug/2001:21:44:35 +] "GET /manual/misc/FAQ.html
> > HTTP/1.1" 32045 119496
> >
> > indicating a 32045 HTTP response code. Anyone have any ideas?
> >
> > --
> > Cheers,
> > Michael
> >
> >
> 
> 

Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c

[William A. Rowe, Jr.]

Well it was busted.  Bad.  Reactivated your patch, Jeff, and started
stepping...

The simple test is set your browser language to en and request;

http://www2.rowe-clan.net:8080/error/HTTP_NOT_FOUND.html.var

If you error 406, the seek (APR_CUR, -value) doesn't work correctly.
It got as far as language de, read the body, and never backspaced 
properly to get the next header line.

If you error 506, then we are in the negotation bug (or mod_includes
anti-recursion bug), and clear of our apr file read/buffered seek
fooness.  This bug is a bigger pita, but at least you will know the
apr_file_read/seek stuff is good :)

The win32 patch is committed.  If we reseek I'm certain we aught to
reset the hit_eof flag.  Be certain your platform is updated.

OTOH, this whole schema is a bit bogus - implemented buffered files
three different ways to sunday is no way to build a reliable library :(

Bill



- Original Message - 
From: "Jeff Trawick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 3:42 PM
Subject: Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c


> [EMAIL PROTECTED] writes:
> 
> > trawick 01/08/24 04:35:58
> > 
> >   Modified:modules/mappers mod_negotiation.c
> >   Log:
> >   temporarily back out the buffering of .var files while folks
> >   have a chance to get APR ungetc working properly on buffered
> >   files
> 
> Is this working on Win32 yet?  
> 
> >   --- mod_negotiation.c 2001/08/24 10:40:04 1.76
> >   +++ mod_negotiation.c 2001/08/24 11:35:58 1.77
> >   @@ -889,7 +889,7 @@
> >/* We are not using multiviews */
> >neg->count_multiviews_variants = 0;
> >
> >   -if ((status = apr_file_open(map, rr->filename, APR_READ | APR_BUFFERED,
> >   +if ((status = apr_file_open(map, rr->filename, APR_READ /* | APR_BUFFERED 
>*/,
> 
> -- 
> Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
>http://www.geocities.com/SiliconValley/Park/9289/
>  Born in Roswell... married an alien...
> 

Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:52 PM


> If you error 506, then we are in the negotation bug (or mod_includes
> anti-recursion bug), and clear of our apr file read/buffered seek
> fooness.  This bug is a bigger pita, but at least you will know the
> apr_file_read/seek stuff is good :)

wrowe   01/08/23 21:16:29

  Modified:modules/mappers mod_negotiation.c
  Log:
Add the config of the ForceLanguagePriority directive, since we seem
to agree on what it does.  My last question is where do I force this
behavior without tons of extra filesystem/cpu consumption?
  
  Revision  ChangesPath
  1.75  +45 -10httpd-2.0/modules/mappers/mod_negotiation.c
  
  Index: mod_negotiation.c
  ===
  RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_negotiation.c,v
  retrieving revision 1.74
  retrieving revision 1.75
  diff -u -r1.74 -r1.75
  --- mod_negotiation.c 2001/08/24 03:04:44 1.74
  +++ mod_negotiation.c 2001/08/24 04:16:29 1.75
  @@ -925,7 +960,7 @@
break;
   }
   mime_info.bytes = len;
  -mime_info.file_name = rr->filename;
  +mime_info.file_name = apr_filename_of_pathname(rr->filename);
   }
   }
   else {
  

Well there's that bug.  Actually, not a bug, but it stopped triggering the 
neg->is_transparent flag when we have a body.  Now if we didn't have a body
with that .var map file, then this is the correct error.  Since we are on
_the_ file they've asked for (or we've decided to serve as an error), the
patch I just committed will take kindly to this body and go ahead and serve it.

Notice that I made this change on purpose, I'm looking for the obvious places we
give away to much local information about the server.  This was one example.
If you looked with language cz (not supported), you would have seen the full
path of the file, repeated four times (de, en, es, fr).  I've backed out this
patch, I have a feeling that we should do such cleanup in the not acceptable
block when we format alternatives for the user.

Bill

Re: [PATCH] Re: chunking of content in mod_include?

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 8:57 AM


> On Monday 27 August 2001 23:27, Brian Pane wrote:
> 
> > How does this patch look?  It does the check only on bucket
> > boundaries, and it pushes out the buffered content if either:
> >   * the amount of buffered content is too large, or
> >   * the apr_bucket_read would block.
> >
> > +if (rv == APR_EAGAIN) {
> 
> This needs to be if (APR_STATUS_IS_EAGAIN(rv)) {
> 
> EAGAIN is one of those annoying error conditions, that is completely non-portable,
> so we have to use a macro to check for it.

For those of you coming on to apr or httpd development recently (I count at least
five active patch submitters that haven't been here all that long) ... let me tell
a fast story.

Most non-unixes don't map directly to errno.  We started with a lookup table and
some other bogus stuff to try mapping errors.  It's horribly slow and a poor solution.
Even some Unix errors have this problem with EAGAIN/EWOULDBLOCK.  But PLEASE don't
simply code correctly in this one case, code consistently!

Anyone writing (rv == APR_ESOMETHING) is asking for problems.  That's why we implement
and maintain that APR_STATUS_IS_ESOMETHING() set of macros.  They are fast (no time
difference on Unix at all) and legible in mainline code.

Unless you are looking at an APR-defined status please use APR_STATUS_IS_EFOO to avoid
some difficult to debug bugs from creeping into the code.

Bill

Re: cvs commit: httpd-2.0/docs/conf httpd-std.conf httpd-win.conf

[William A. Rowe, Jr.]

From: "Joshua Slive" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 12:57 PM


> On 28 Aug 2001 [EMAIL PROTECTED] wrote:
> 
> > wrowe   01/08/28 08:29:21
> >
> >   Modified:docs/conf httpd-std.conf httpd-win.conf
> >   Log:
> > Someone pointed out that we were running the images through the INCLUDE
> > filter.  This fixes it, in a sort of hackish way.
> > I don't remember who noticed this, sorry :(
> 
> Great.  Two quick points:
> 
> 1. This doesn't matter at the moment, because I removed the image from the
> error docs in my "great simplification".
> 
> 2. I think that this is a better configuration anyway.  In fact, I plan to
> change all the SSI docs to recommend using AddInputFilter in place of
> SetInputFilter.  The latter makes mistakes like this too darn easy.

Slow down :)  The next patch to come introduces AddInputFilterByType and
AddOutputFilterByType - which allows mime-ish configuration :)

Bill

Re: [PATCH] mod_autoindex HeaderName/ReadmeName content_type

[William A. Rowe, Jr.]

This is a wee bit to hackish.  Proper configuration of the files is more
appropriate.  On Apache 1.3, I believe the hack that works is

AddType /README text/plain
AddType /HEADER text/plain

Please don't ask why this should work ... is just does ;)

Give it a shot, let us know if it solves your problem without hassle.

Bill

- Original Message - 
From: "Robert Simonson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 8:41 AM
Subject: [PATCH] mod_autoindex HeaderName/ReadmeName content_type


> This patch is to set the content_type to the default if the subrequest
> request_rec content_type is NULL.
> 
> Rob Simonson
> [EMAIL PROTECTED]
> 
> ==
> --- mod_autoindex.c.asfsave.c Wed Aug 29 08:29:17 2001
> +++ mod_autoindex.c Wed Aug 29 08:32:15 2001
> @@ -999,49 +999,49 @@
>  && (rr->status == HTTP_OK)
>  && (rr->filename != NULL)
>  && rr->finfo.filetype == APR_REG) {
> +if (rr->content_type == NULL)
> +rr->content_type = ap_default_type(rr);
>  /*
>   * Check for the two specific cases we allow: text/html and
>   * text/anything-else.  The former is allowed to be processed for
>   * SSIs.
>   */
> -if (rr->content_type != NULL) {
> -if (!strcasecmp(ap_field_noparam(r->pool, rr->content_type),
> -  "text/html")) {
> - /* Hope everything will work... */
> - emit_amble = 0;
> - emit_H1 = 0;
> +if (!strcasecmp(ap_field_noparam(r->pool, rr->content_type),
> +"text/html")) {
> +/* Hope everything will work... */
> +emit_amble = 0;
> +emit_H1 = 0;
> 
> - if (! suppress_amble) {
> - emit_preamble(r, title);
> - }
> - /*
> -  * If there's a problem running the subrequest, display the
> -  * preamble if we didn't do it before -- the header file
> -  * didn't get displayed.
> -  */
> - if (ap_run_sub_req(rr) != OK) {
> - /* It didn't work */
> - emit_amble = suppress_amble;
> - emit_H1 = 1;
> - }
> -}
> -else if (!strncasecmp("text/", rr->content_type, 5)) {
> - /*
> -  * If we can open the file, prefix it with the preamble
> -  * regardless; since we'll be sending a  block around
> -  * the file's contents, any HTML header it had won't end up
> -  * where it belongs.
> -  */
> - if (apr_file_open(&f, rr->filename, APR_READ,
> -APR_OS_DEFAULT, r->pool) == APR_SUCCESS) {
> - emit_preamble(r, title);
> - emit_amble = 0;
> - do_emit_plain(r, f);
> - apr_file_close(f);
> - emit_H1 = 0;
> - }
> -}
> -}
> +if (! suppress_amble) {
> +emit_preamble(r, title);
> +}
> +/*
> + * If there's a problem running the subrequest, display the
> + * preamble if we didn't do it before -- the header file
> + * didn't get displayed.
> + */
> +if (ap_run_sub_req(rr) != OK) {
> +/* It didn't work */
> +emit_amble = suppress_amble;
> +emit_H1 = 1;
> +}
> +}
> +else if (!strncasecmp("text/", rr->content_type, 5)) {
> +/*
> + * If we can open the file, prefix it with the preamble
> + * regardless; since we'll be sending a  block around
> + * the file's contents, any HTML header it had won't end up
> + * where it belongs.
> + */
> +if (apr_file_open(&f, rr->filename, APR_READ,
> +  APR_OS_DEFAULT, r->pool) == APR_SUCCESS) {
> +emit_preamble(r, title);
> +emit_amble = 0;
> +do_emit_plain(r, f);
> +apr_file_close(f);
> +emit_H1 = 0;
> +}
> +}
>  }
> 
>  if (emit_amble) {
> @@ -1082,32 +1082,32 @@
>  && (rr->status == HTTP_OK)
>  && (rr->filename != NULL)
>  && rr->finfo.filetype == APR_REG) {
> +if (rr->content_type == NULL)
> +rr->content_type = ap_default_type(rr);
>  /*
>   * Check for the two specific cases we allow: text/html and
>   * text/anything-else.  The former is allowed to be processed for
>   * SSIs.
> - */
> -if (rr->content_type != NULL) {
> -if (!strcasecmp(ap_field_noparam(r->pool, rr->content_type),
> -  "text/html")) {
> - if (ap_run_sub_req(rr) == OK) {
> - /* worked... */
> - suppress_sig = 1;
> - suppress_post = suppress_amble;
> - }
> -}
> -else if (!strncasecmp("text/", rr->content_type, 5)) {
> - /*
> -  * I

Re: mod_tls

[William A. Rowe, Jr.]

From: "Gonyou, Austin" <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 11:48 AM


> The referrence here is one about all the filters used by apache 2.0. If
> there is a filter bucket in APR, it's understandable that Apache 2.0 modules
> will have 2 parts. The logic piece and the filter piece. As far as I can
> tell, the filter mechanism allows for some distinct advantages and makes for
> a very flexible configuration framework. My issue here is that if mod_tls is
> sacrificed, then what's the point of using filters at all anyway? That said,
> could it be said that you CAN write a module for Apache 2.0 without needing
> the use of filters? If so, then that makes sense. 

I think we are confusing Content filters with Connection Filters.

Connection Filters can rarely be divorced from the protocol.  E.g., chunking
and byterange filters can't be split (easily) from the http protocol.  An ssl
filter can't be split from the negotiation of the ssl conversation.

When we implement Connection-Upgrade (SSL over IP) then the extention needs
to be burried directly into mod_ssl's https layer.

I can only see splitting this into two parts from it's current state.  One part
would be the https module.  The other part would be all the client negotiation
that's left over, with hooks between.

I'm not certain we wish to 'extend' tls into this connection aspect.  To get
it right, it's easier to split out https_protocol and proxy_https from the
rich set of mod_ssl features.  Then the ssh protocol will stand alone, with an
appropriate _protocol module, for future expansion.

I'm going to state, right now, that I see this (and the further 'rearrangement'
of modules/http into a stand-alone/removable component) as httpd-2.1 features.
Right now modules/http contains a lot of core features, and the core still contains
a bunch of http features.

The third split in 2.1 would be mod_filesystem, for all the file hackishness in
the core today ;)

So I'll call these for a vote...

  a removable modules/http (fully segregated from core) is not an Apache 2.0 
showstopper.

  a removable modules/https (fully segregated from mod_ssl) is not an Apache 2.0 
showstopper.

  a removable mod_filesystem (fully segregated from core) is not an Apache 2.0 
showstopper.

  These above-mentioned features, once complete, will instigate the 2.1 bump. 

  Today, we pull mod_tls from the distribution till we do the split above for 2.1.

This doesn't mean we don't continue to focus on Content filters until the semantics are
right (see my next post a bit later) - it just means that Connection filters have some 
growing to do :)

Bill

Re: time for 2.0.25?

[William A. Rowe, Jr.]

Doug,

  the mod_proxy group's autobuild kicks some a$$!  Would it be possible to get
the test build system set up and automailing on a nightly basis, so Win32 folks
and others without the time to follow the test environment discovers these things 
very soon after their patches?  I plead guilty, I'd really like to help undo 
breakage that I cause whereever I can.

Bill

- Original Message - 
From: "Doug MacEachern" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 1:04 PM
Subject: Re: time for 2.0.25?


> On 29 Aug 2001, Ian Holsman wrote:
> 
> > apache.org seems to have been running .24 (+mod_include fix)
> > for a while now (>3days).
> > 
> > How about we Tag&Roll .25 put it up on apache.org and if all goes 
> > well monday will be beta2 day.
> 
> recent-ish changes have broken the sh*t out of modperl-2.0 "make test".
> far worse than i've seen in months, normal breakage is just due to api
> changes.
> some are related to the location/directory walk changes, some are related
> to filters somehow.  but i have not had a chance to debug yet.
> 
> 

Re: PHP4 as CGI with 2.0.25

[William A. Rowe, Jr.]

From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 2:24 PM


>   Hi there,
> 
>   I just updated to 2.0.25 on my Win32 system, where I have the
>   following lines in the httpd.conf to use PHP 4 as CGI
> 
> ScriptAlias /php/ "e:/server/php/"
> AddType application/x-httpd-php .php
> Action application/x-httpd-php "/php/php.exe"
> Action application/x-httpd-php-source "/php/php.exe"
> 
>   This worked fine until now. Now I only get an
> 
> The requested URL /php/php.exe/index.php was not found on 
> this server.
> 
>   error when trying to access /index.php.
> 
>   Were there any changes that I might have missed?

Yes, the directory negotiation and AddType handling.  I need to walk back
now and look at the action directive.  Perhaps I interfered with it, or
perhaps it's interfering with my patch.

I hope to have an answer today.

Also - note that names are -heavily- canonicalized now, so it's possible
that something that just 'slipped through' in spite of one of the 
ap_os_canonicalize_filename flavors is now caught.  Likewise, I've tried
to catch every abuse of ap_make_full_path and toggle it to apr_filepath_merge,
leaving ap_make_full_path stuff to merge URIs.  I may have missed the correct
choice to treat-as-uri, or to treat-as-path.

Finally, ap_directory_walk now insists on real file names.  If a module will
circumvent the filesystem (e.g. it invents a bogus filename _just to get by_,
we should now catch that.)  An entry should appear in your error log.

If a module (or an action - I'll look!) needs to bypass the filesystem to do
funny business, that's fine, it just returns an OK result code from the new
map_to_storage hook (register it simply as APR_HOOK_MIDDLE) if it can claim
the request.

This alone should eliminate entire classes of security advisories that have
revolved around canonical paths, 'tricking the server' into serving instead
of parsing dynamic content, etc.  More work remains, but this was the underpinning.

Bill

Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page

[William A. Rowe, Jr.]

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 5:24 PM
Subject: Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page


> On Wed, Aug 29, 2001 at 04:14:39PM -0600, Charles Randall wrote:
> > Using the prefork mpm on FreeBSD 4.2-R with a default installation
> > (./configure --prefix=/my/full/path -with-port=8080) a request for a
> > non-existant page (E.g., /bogus) returns the HTML error document as
> > text/plain.
> 
> Yup, that's a bug.  I don't *think* it is a showstopper though.  I can
> reproduce this here.  I was just looking to not have the 506 error -
> I didn't even pay attention to the content-type returned.

Outch.  But if we were mis-parsing the .var file due to the apr_file_seek
and apr_file_gets implementations, then this could be expected.

I'll try reproducing on Win32.

[Dang me for testing with IE!  Mozilla from now on, promise!!!  Whatever
happened to that little 'show http headers' feature from Mozilla .91???]

Broken SetOutputFilter/SetInputFilter semantics

[William A. Rowe, Jr.]

Folks,

  I'm working on the AddOutputFilterByType/AddInputFilterByType patch to core.c.
I'll drop it into core.c, since we only have three other ByType directives (AddIcon
and AddDesc from mod_autoindex, and ExpiresByType in mod_expires.)

  I discovered something's pecular about SetOutputFilter/SetInputFilter.  Unlike every
similar SetFoo directive, we keep stacking them on, and have no remove function.
Warning; I'm discussing _only_ content filters here, connection and parent request 
filters aren't even considered!!!



  Essentially, a user trying a SetFoo function expects it to override any SetFoo
in a parent resource (.htaccess over ,  over , 
over  and  over .)

  Right now we add 'just one more'.  But we can't take them out.  This is borked.

  In the mod_mime patch I tossed in yesterday, each recognized extension can add 
filters 
(in the order the extensions occur in the filename, L2R order.)  But I added the 
corresponding RemoveInputFilter/RemoveOutputFilter the filename association in a 
nested 
container.  And each AddInputFilter directive _replaces_ the previous AddInputFilter 
directive for that same extention.



  Note that SetHandler shares part of this problem, it can't be overriden in a nested 
container.  This is wrong, so consider that UnSetHandler (no arg) will undo that 
problem.
Therefore SetFooFilter filters gets an UnSetFooFilters (no arg), and either can be 
undone
in a child container.  That's part of the problem, so onwards...



  That means that RemoveFooFilter BogusFilter .bak will take any filters away from the
.bak extension that were defined before for the .bak extension.  That does NOT mean 
that .bak will cause other extensions to be removed, so foo.shtml.bak would KEEP it's 
Includes filter.  That is how Add|Remove mod_mime things work.

  For mod_mime's semantics, the syntax is AddFooFilter filters ext [ext...].  We could 
not 
use the semantic AddFooFilters filter [filter...] ext since it's ambigious. Instead I 
used 
semicolons to allow multiple filters for the same extension, so an shtml-gz *could* be
defined to run through GUnZip;Includes (not that I see many doing this.  It will be an
obscure, rarely used but useful feature.)

  So now we have a ton of extensions adding filters, will soon have AddFooFilterByType
adding filters, and finally SetFooFilter adding more at the end.  Handlers were never
this difficult to configure :(

  I'm suggesting, today, that we support the following syntax for all these directives;

{Add|Remove}{Input|Output}Filter [+|-]foo[;[+|-]bar...] ext [ext...]

{Add|Remove}{Input|Output}FilterByType [+|-]foo[;[+|-]bar...] [mime-type]

Set{Input|Output}Filter [+|-]foo[;[+|-]bar...]   OR  UnSet{Input|Output}Filter

  Again, UnSetFooFilter takes no args, it undoes the SetFilter, that's all.  It has no 
effect on the Add/RemoveFooFilter stuff.  Apache will get an UnSetHandler that does the
very same thing.

---

  These filters would be run in the order above.  An absolute syntax in any of the 
above
will CLEAR the content filter list.  Any of these directives will OVERRIDE the prior
definition of the same directive.  So in this example;

AddOutputFilter +charset .utf-8

AddOutputFilter +includes .shtml


SetOutputFilter none



SetOutputFilter +decoration



UnSetOutputFilter


  If we ask for the file /something/test.utf-8.shtml, mod_mime hits utf-8, which adds 
the 
charset filter, we hit .shtml, which adds includes, and then the core filter clears 
them
all.

  If we ask for the file /webroot/test.utf-8.shtml, when the core filter merged the
 blocks it started with none, then changed it's mind to +decoration.  So mod_mime 
hits 
utf-8, which adds the charset filter, then .shtml, which adds includes and the core 
filter 
adds the decoration filter.

  If we ask for the file /webroot/someweb/test.shtml, mod_mime adds includes, and then
the core filter (after merging the  blocks) doesn't change a thing.



  I'm suggesting ALL of these filters run in the mime negotation and fixups phase.  
That
way, any module that uses the insert_filters hook will ALWAYS override these user 
configured
filters, so that modules will rarely be broken by user configuration errors.  Here are 
the
phases I suggest;

mime_types hook  :::  Add[foo]OutputFilter is run in mod_mime's hook

fixups hook  :::  Add[foo]OutputFilterByType is run in the core's hook

insert_hooks :::  SetHandler (absolute) is run in the core's hook



  If we don't get this right, httpd-2.0 will be resoundingly booed by the Administrator
community a year from now.  Please - help me out with your comments ;)

Bill

Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page

[William A. Rowe, Jr.]

Netcat 1.1 usually does fine for me, but I'm usually looking at whole content,
not just headers :(  It was kind of handy when the lat Mozilla offered that
panel... now I dunno where it's disappeared to.

- Original Message - 
From: "Jerry Baker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 8:06 PM
Subject: Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page


> "William A. Rowe, Jr." wrote:
> > 
> > I'll try reproducing on Win32.
> > 
> > [Dang me for testing with IE!  Mozilla from now on, promise!!!  Whatever
> > happened to that little 'show http headers' feature from Mozilla .91???]
> 
> I dunno, but I have a tiny little VB utility to get HTTP headers without
> having to do the whole telnet thing. Lemme know if you want it.
> 
> -- 
> Jerry Baker
> 
> PGP Key: http://www.jerrybaker.org/pgp.html
> 
> LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
> Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
> 

Re: please make SIG_GRACEFUL configurable

[William A. Rowe, Jr.]

From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 8:21 PM


> and then make it configurable using configure [default=SIGUSR1].  To make
> it even better, we should have a way to signal it using httpd itself
> 
> httpd restart
> httpd graceful
> httpd stop
> 
> would check for an existing process and send it the appropriate signal.
> That way we wouldn't be spreading implementation assumptions throughout
> the support code.

Can we _please_ agree on semantics, finally, to bring httpd/win32 and httpd/others
in sync again?  We use the -k start|stop|restart semantic, could easily add
graceful with it's proper meaning (and make restart a hard restart, as it was in
the very early win32 version.

Bill

Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page

[William A. Rowe, Jr.]

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 10:29 PM


> On Wed, Aug 29, 2001 at 08:20:38PM -0700, Justin Erenkrantz wrote:
> > HEAD looks like it has this problem fixed (the buffered read fixes 
> > perhaps?).  Please check it out and see if it works for you with
> > the latest CVS.  
> 
> No, it's not fixed.  My bad.
> 
> I had a stale config which had SetOutputFilter instead of 
> AddOutputFilter for the error pages.  What does SetOutputFilter
> do that AddOutputFilter doesn't?
> 
> I'm drilling down to see what's up.  -- justin

Nothing that Apache hasn't done forever (incorrectly)  :(

Patch in 3 minutes.

Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 10:49 PM


> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Wednesday, August 29, 2001 10:29 PM
> 
> > On Wed, Aug 29, 2001 at 08:20:38PM -0700, Justin Erenkrantz wrote:
> > > HEAD looks like it has this problem fixed (the buffered read fixes 
> > > perhaps?).  Please check it out and see if it works for you with
> > > the latest CVS.  
> > 
> > No, it's not fixed.  My bad.
> > 
> > I had a stale config which had SetOutputFilter instead of 
> > AddOutputFilter for the error pages.  What does SetOutputFilter
> > do that AddOutputFilter doesn't?
> > 
> > I'm drilling down to see what's up.  -- justin
> 
> Nothing that Apache hasn't done forever (incorrectly)  :(
> 
> Patch in 3 minutes.

Committed.

Essentially, we used AddOutputFilter includes >html<, which broke mime.
It's done this forever, but it wasn't common ... how often did you set the
Encoding, Charset, Language or Handler on 'html'?  If you did - you broke
(unless you added a _corresponding_ AddType text/html >html<.

We just skipped the mime.types file altogether since the .html record was
found in the extension info within the /serverroot/error/ directory block,
having set AddOutputFilter.  This would have been reported frequently with 
these two new filtering directives.

Bill

Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page

[William A. Rowe, Jr.]

Pretty danged close :)  Good job (probably would have lost the race I hadn't
just memorized every line of that code in the last two weeks ;)

We really can skip it if exinfo->forced_type is set, though.  That overrides
all other mime types.

Bill

- Original Message - 
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 11:02 PM
Subject: Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page


> On Wed, Aug 29, 2001 at 10:49:31PM -0500, William A. Rowe, Jr. wrote:
> > From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 29, 2001 10:29 PM
> > 
> > 
> > > On Wed, Aug 29, 2001 at 08:20:38PM -0700, Justin Erenkrantz wrote:
> > > > HEAD looks like it has this problem fixed (the buffered read fixes 
> > > > perhaps?).  Please check it out and see if it works for you with
> > > > the latest CVS.  
> > > 
> > > No, it's not fixed.  My bad.
> > > 
> > > I had a stale config which had SetOutputFilter instead of 
> > > AddOutputFilter for the error pages.  What does SetOutputFilter
> > > do that AddOutputFilter doesn't?
> > > 
> > > I'm drilling down to see what's up.  -- justin
> > 
> > Nothing that Apache hasn't done forever (incorrectly)  :(
> > 
> > Patch in 3 minutes.
> 
> Let's see how close I am.  I think it has something to do with this
> logic.  We should always look in mime_type_extensions, or so I
> think...
> 
> A complete shot-in-the-dark...  I feverishly await your commit.  
> -- justin
> 
> Index: mod_mime.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
> retrieving revision 1.60
> diff -u -r1.60 mod_mime.c
> --- mod_mime.c 2001/08/28 15:31:08 1.60
> +++ mod_mime.c 2001/08/30 04:00:04
> @@ -740,14 +740,11 @@
> ext, APR_HASH_KEY_STRING);
>  }
>  
> -if (exinfo == NULL) {
> -if ((type = apr_hash_get(mime_type_extensions, ext,
> - APR_HASH_KEY_STRING)) != NULL) {
> -r->content_type = type;
> -found = 1;
> -}
> +if ((type = apr_hash_get(mime_type_extensions, ext,
> + APR_HASH_KEY_STRING)) != NULL) {
> +r->content_type = type;
>  }
> -else {
> + if (exinfo != NULL) {
>  
>  if (exinfo->forced_type) {
>  r->content_type = exinfo->forced_type;
> 
> 

Re: cvs commit: httpd-2.0/server core.c

[William A. Rowe, Jr.]

If you thought this patch;

>   --- mod_mime.c 2001/08/28 15:31:08 1.60
>   +++ mod_mime.c 2001/08/30 04:11:57 1.61
>   @@ -116,8 +116,6 @@
>
>apr_array_header_t *remove_mappings; /* A simple list, walked once */
>
>   -char *type; /* Type forced with ForceType  */
>   -char *handler;  /* Handler forced with SetHandler */
>char *default_language; /* Language if no AddLanguage ext found */
>/* Due to the FUD about JS and charsets 
> * default_charset is actually in src/main */

seemed to have nothing to do with exinfo/mime.types, you are right :(  This was
work left over from this afternoon, which I completely forgot about while debugging
the ErrorDocument as text/plain bug.

I am certain it belongs in core.c.  What I'm less certain about is why it must become
a fixups phase.  I'd like to fix this in the morning, so please read the following
diatribe and comment.

Type checking is far more complex than a 'single variable' - we can't continue this
way.  If mod_mime figures a file is Language es, and nothing more, then we need to
have mod_mime_magic finish the job.  Actually, we need to start with this forced
handler/type and end with the forced handler/type, so it's optimized (we don't want
to mod_mime_magically consume cpu) but involatile (unless a fixups hook wishes to
play games.)  So if type_checker becomes run-all - I'll make this fn run both as
very first and very last in the type_checker hook (instead of fixups.)


Bill



> wrowe   01/08/29 21:24:10
> 
>   Modified:include  http_core.h
>server   core.c
>   Log:
> Since the mod_mime patch was applied, here is the rest of the patch to
> introduce the ForceType and SetHandler [absolute references] directly
> into the very top of the fixups phase.  This means these will always
> override _any_ mime module, not just mod_mime.  Ergo, other mime modules
> can continue to set charset, encodings, etc.  Since these are globals,
> they belong in the core.
>   
> This highlights a very serious drawback to the type_checker hook.  By
> using run first, a module that identifies _partial_ information (maybe
> just the content type) won't pass the query on to other modules, like
> mod_mime, that might further define the encoding or charset.  The
> type_checker hook should clearly become a run-all, and the modules should
> decline if they see someone ahead of them answered a question they were
> going to try to figure.
>   
> Which means - if type_checker becomes RUN_ALL - this new override hook
> fn should become a type_checker again - and RUN_REALLY_FIRST, and let
> other modules _choose_ not to override this election.  (We can run it
> again at the end, for a recount ;)  Votes?
>   
>   Revision  ChangesPath
>   1.50  +4 -2  httpd-2.0/include/http_core.h
>   
>   Index: http_core.h
>   ===
>   RCS file: /home/cvs/httpd-2.0/include/http_core.h,v
>   retrieving revision 1.49
>   retrieving revision 1.50
>   diff -u -r1.49 -r1.50
>   --- http_core.h 2001/08/26 05:10:17 1.49
>   +++ http_core.h 2001/08/30 04:24:09 1.50
>   @@ -463,8 +463,10 @@
>interpreter_source_e script_interpreter_source;
>#endif
>
>   -apr_array_header_t *output_filters;
>   -apr_array_header_t *input_filters;
>   +char *mime_type; /* forced with ForceType  */
>   +char *handler;   /* forced with SetHandler */
>   +apr_array_header_t *output_filters;  /* forced with SetOutputFilters */
>   +apr_array_header_t *input_filters;   /* forced with SetInputFilters */
>} core_dir_config;
>
>/* Per-server core configuration */
>   
>   
>   
>   1.53  +41 -1 httpd-2.0/server/core.c
>   
>   Index: core.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/server/core.c,v
>   retrieving revision 1.52
>   retrieving revision 1.53
>   diff -u -r1.52 -r1.53
>   --- core.c 2001/08/28 15:45:01 1.52
>   +++ core.c 2001/08/30 04:24:09 1.53
>   @@ -160,6 +160,10 @@
>conf->add_default_charset = ADD_DEFAULT_CHARSET_UNSET;
>conf->add_default_charset_name = DEFAULT_ADD_DEFAULT_CHARSET_NAME;
>
>   +/* Overriding all negotiation 
>   + */
>   +conf->mime_type = NULL;
>   +conf->handler = NULL;
>conf->output_filters = apr_array_make(a, 2, sizeof(void *));
>conf->input_filters = apr_array_make(a, 2, sizeof(void *));
>return (void *)conf;
>   @@ -301,6 +305,15 @@
>conf->add_default_charset_name = new->add_default_charset_name;
>}
>}
>   +
>   +/* Overriding all negotiation 
>   + */
>   +if (new->mime_type) {
>   +conf->mime_type = new->mime_type;
>   +}
>   +if (new->hand

Re: 2.0.26?

[William A. Rowe, Jr.]

No docs change needed (see the previous note to the list.)

- Original Message - 
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 11:20 PM
Subject: Re: 2.0.26?


> On Wed, Aug 29, 2001 at 09:18:00PM -0700, Justin Erenkrantz wrote:
> > I'm verifying wrowe's commit right now.  It looks right.  =)
> > See if it works right...
> 
> wrowe's commit took out SetHandler (on purpose??) which means that 
> the server-status conf example needs to change.  Trying to figure 
> out what it should be.  -- justin
> 
> 

Re: cvs commit: httpd-2.0/os/unix unixd.h

[William A. Rowe, Jr.]

Two general unix problems to fix before tommorows tag.

From: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 12:11 AM


> wrowe   01/08/29 22:11:42
> 
>   Modified:os/unix  unixd.h
>   Log:
> No  under cygwin.
>   
>   Revision  ChangesPath
>   1.26  +4 -0  httpd-2.0/os/unix/unixd.h
>   
>   Index: unixd.h
>   ===
>   +#ifdef HAVE_SYS_TYPES_H
>#include 
>   +#endif
>   +#ifdef HAVE_SYS_IPC_H
>#include 
>   +#endif

I know HAVE_SYS_TYPES_H is lying around, dunno if we need a new HAVE_SYS_IPC_H test.

Also, please review and commit (or reject) the following patch;

From: "Stipe Tolj" <[EMAIL PROTECTED]>
Sent: Saturday, August 11, 2001 6:35 AM

>   * srclib/apr/file_io/unix/dir.c: changed a suspicious #ifdef
> statement. Is this a missconfiguration of thread vs. non-thread #ifdef
> exclusion?!?!

--- httpd-2_0_22/srclib/apr/file_io/unix/dir.c Fri Jun 15 20:04:43 2001
+++ httpd-2_0_22-cygwin/srclib/apr/file_io/unix/dir.c Thu Aug  9 10:00:09 2001
@@ -112,7 +112,7 @@
 {
 apr_status_t ret = 0;
 #if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS) \
-&& !defined(READDIR_IS_THREAD_SAFE)
+&& defined(READDIR_IS_THREAD_SAFE)
 struct dirent *retent;
 
 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);


I'm not exactly certain _what_ READDIR_IS_THREAD_SAFE means, that we have a
readdir_r that's useless, or that we have one we aught to use.

Re: [PATCH] 2.0.x pre-alpha support for Cygwin

[William A. Rowe, Jr.]

From: "Stipe Tolj" <[EMAIL PROTECTED]>
Sent: Saturday, August 11, 2001 6:35 AM


> Attached is a first patch to support the Cygwin 1.x platform. 
> 
> It is made against 2.0.22-alpha, due to the fact that I am currently
> on vacation and don't have the bandwidth (GSM modem :(( to grap a
> fresh CVS tree. Hope someone with commit access to CVS can incorporate
> the changes anyway, Martin?!

Done, except as noted below.

I'll stop and pause just a moment so we don't continue to have the same
somewhat frustrating conflict (for both of us ;) and add my 2c, which I
believe are the general concensus.

I'd like to specifically request that you do not imply that the cygwin support
in Apache 2.0 is provided for the "Windows" platform, but only for the "cygwin"
platform.  That is, there is native Win32 support built into the server, for the 
native Win32 filesystem and system calls.  In fact, APR has turned this entire 
concept on it's head, so that Apache could even support Mac OS 9 (gasp!!!)

That said, I am a strong supporter of our users (anyone who drops in on
c.i.w.s.ms-windows can attest :) so I'd like to assure we leverage as much
common code to support these unix wolves trapped in win32 sheep's clothing.  
Please refer to the file in srclib/apr/file_io/win32/pathname.c for the reference 
to the canonicalization facilities in Apache 2.0.  I expect you will want to 
leverage a cygwin optimized flavor of apr_stat/lstat that returns the proper (long)
filename, but substitute the appropriate path rooting for the cygwin platform.  
You may also (with just a little bit of thunking) implement detection of the 
shortcuts-as-symlinks (which I detest :) in your lstat call, so that FollowSymLinks
functionallity is properly supported under the cygwin platform.

Please take the time to study pathname.c, since OS2 and Netware already share that
code branch.  The Unix branch will eventually be extended to properly handle samba
shares (the one weakness in Apache on unix, no surprize) but that's probably not
sufficient for cygwin.

Finally, I'll encourage anyone who wants to offer up a mingw toolchain schema
of the Apache build environment, as it uses the native api and semantics.  I'd
be happy to assist in dealing with some of the newer api's that aren't there just
yet - when I'm able.

Here are my comments on the two exceptions to your patch (and yes - the change to
the config.guess in apr was previously commited.)

> 2.0.22 configures, build and runs with prefork MPM (non-threaded) on
> Cygwin 1.1.8 and 1.3.2. Cygwin 1.3.2 supports pthreads, but I have
> still problems in getting the threaded MPM to work, so that's why
> prefork is assumed as default MPM. 

That's fine.  However...

I see no reason not to enable threads, unless you have a specific issue,
even when running prefork.  Feel free to correct me.  This obviously will
be a versioning issue, from your comments, so I dropped the following lines
from this patch...

--- httpd-2_0_22/srclib/apr/configure.in Fri Jul 27 10:22:04 2001
+++ httpd-2_0_22-cygwin/srclib/apr/configure.in Fri Aug 10 09:41:03 2001
+   enable_threads="no"
+   config_subdirs="shmem/unix/mm"

The others were applied, but this line struck me as odd;

+   eolstr="\\n"

true, I suppose, if the user entirely edits in cygwin/gnu/vi, but not if they
pick up a conf file in notepad :(

>   * srclib/apr/file_io/unix/dir.c: changed a suspicious #ifdef
> statement. Is this a missconfiguration of thread vs. non-thread #ifdef
> exclusion?!?!

I am leaving the question of this patch to the more gifted.  I see where you
are coming from, but I read the original (and patch) three times, and came to
three different conclusions.  Someone want to determine before we tag and roll?


--- httpd-2_0_22/srclib/apr/file_io/unix/dir.c Fri Jun 15 20:04:43 2001
+++ httpd-2_0_22-cygwin/srclib/apr/file_io/unix/dir.c Thu Aug  9 10:00:09 2001
@@ -112,7 +112,7 @@
 {
 apr_status_t ret = 0;
 #if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS) \
-&& !defined(READDIR_IS_THREAD_SAFE)
+&& defined(READDIR_IS_THREAD_SAFE)
 struct dirent *retent;
 
 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);

Re: PHP4 as CGI with 2.0.25

[William A. Rowe, Jr.]

Sebastian,

  that's the bug I'm attacking, at the moment.  Thanks for the details.

Bill

- Original Message - 
From: "Sebastian Bergmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 9:34 AM
Subject: Re: PHP4 as CGI with 2.0.25


> Jeff Trawick wrote:
> > I put a fix into server/core.c to fix an unbelievably drastic 
> > problem (loop and/or segfault on main path) which was introduced 
> > during the evening. You might want to try it again.
> 
>   The crash is gone now, but the
> 
> The requested URL /php/php.exe/index.php was not found on 
> this server.
> 
>   problem is still there.
> 
> -- 
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/
> 

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 10:09 AM


> At least on this front, I'm in total agreement... the httpd-test suite is
> excellent.  I've gotten to where I rely on it heavily to test any change I
> make (even small ones) before committing, because it's so good at sniffing
> out the subtle (and not-so-subtle) problems.  If everybody used it, we'd
> be set.

Looks like an excellent, well thought ought testbench.  Shame it doesn't run 
everywhere.

If stipe's patches 'take' then we are moving forward.  Of course it cannot test the
native win32 mpm on windows today, only prefork on cygwin.  But if that's a start,
I'll be satisfied.

BTW - I'm committing Stipe's patch to disable threads (well, double checking that
it's the correct patch) since many aspects of threading and foo_r detection are
broken on cygwin.

Bill

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 11:04 AM


> On Thursday 30 August 2001 08:09, Cliff Woolley wrote:
> > On Thu, 30 Aug 2001, Ryan Bloom wrote:
> > > > > We shouldn't do either.  If you go back and read the original thread,
> > > > > one of the general rules of this release strategy is that we don't
> > > > > release every day.  We just rolled a tarball, and announced it to the
> > > > > new-httpd, so there are people testing it at this point.  That
> > > > > tarball has to stand or fall on it's own.  In a week, we can re-roll
> > > > > 2.0.26, and try again.

HuH?  Ok, you rolled a tarball.  Why?  Our first-line testers are capable of
checking out cvs.  Bump a tag (or branch), and a 30 second cvs checkout and
a < three minute make is all it takes to get testing.


> > That's silly.  That makes it very difficult to be sure we're stable again
> > by the time we're "allowed" to tag 2.0.26.  I agree wholeheartedly with
> > whomever it was that said the only problem with our current system is the
> > concatenation of the words "tag" and "roll" into a single "tag&roll"
> > operation.  We need to tag, test for just a little while to sort out the
> > obvious problems that have just bitten 2.0.25, and THEN roll.  Rolling
> 
> That doesn't work.  The last time I tagged, and then waited to roll, I was
> told that I needed to get tarballs up so that people could download them.

WTF?  I don't remember seeing that discussion on the list.  Since oh, about 2.0.21
we've been giving folks the opportunity to test.  You are the only individual who
seems to be tarring as you tag these days.



> > before preliminary tests are done is silly.  Half the time it means that
> > we don't even build on some systems, which we could have found out about
> > if we'd waited an hour to give people a chance to check.  I agree with
> 
> Waiting an hour doesn't do anything.  Most people on this list don't hack
> Apache all day every day.  The whole point of the current system, is that
> we tag when things all look good.  If we are wrong, then we wait a week,
> and try again.

Not if you ever want to get anywhere.  Tomcat has a good model - pay attention
to it - they get releases out the door.


> > Bill that there needs to be a time limit on the duration between the tag
> > and the roll... four days sounds good (if not excessive).  That's what
> > killed 2.0.23 and 2.0.24 in a way... they took too damned long.  At least
> > if we spread it out over a couple days, we don't twiddle our thumbs for a
> > week after we realize that the tarball we just rolled is broken for some
> > piddly-ass reason or another.  Besides, if we wait a day or two between
> > the tag and the roll, there would never BE a reason to release every day,
> > so that problem just vanishes for free.
> 
> You are still asking testers to test multiple versions.  Or, you are going back
> to the 1.3 model, where we hit a code-freeze, so every developer out there
> commits everything they have in their tree just before we go code-freeze.
> That is the problem that killed Apache 1.3.13, 14, 15, 16.

And brought .14, .17, .19 and .20 out the door, as solid as we could expect them
to be under any release model.  But 1.3 code is stable (if not always correct).


> > > And it would go a long way towards pissing off our testers.  We have
> > > people who download the tarball when we release it, and if we replace
> > > that tarball after just a few hours,

Ryan, how many testers lists do we have?  dev@httpd is _NOT_ the tarball test list.
The order must go 

  1. Tag.  Announce as version candidate at [EMAIL PROTECTED]
  2. wait for folks to build and regress (24 hours???)
  3. vote.  Is the feedback [at least] alpha quality?  Are there no beta showstoppers?
  4. bump subrevision to -alpha [optional - but I think we need to go here]
  5. Tar.  Announce as beta candidate at [EMAIL PROTECTED]
  6. wait for folks to build, regress, and stress (72 hours???)
  7. vote.  Is the feedback [at least] beta quality?  Are there no release 
showstoppers?
  8. bump subrevision to -beta [optional - but I think we need to go here]
  9. Tar.  Announce as release candidate at [EMAIL PROTECTED]
 10. wait for folks to build, regress, and further stress (one week???).  
 11. The Adventuous may experiment with installing to production on non-critical 
servers.
 12. vote.  Is the feedback of release quality?  Are there no new showstoppers?
 14. bump subrevision to -gold.
 15. Tar.  Up to www.apache.org/dist/.  Broadcast the release 

There will be no changes to a -gold release, ever.  We could subversion the -alpha and
-beta versions, e.g. 2.0.25.-alpha.  I propose the number of days since the 
official
release of Apache 1.0 ;)


> > Whoa... time out.  I'm saying (and I think Bill is, too), that we *do not*
> > replace the tarball.  Once it's rolled, that's it.  If the tarball's
> > broken, try again with a new tag later.  We can easily test it for obvious
> > flaws

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 11:55 AM


> Not really. The process Cliff and I outlined is really aimed at getting -a- stable 
>release
> available. The process will take at least 2 days to go through but shouldn't take 
>more
> than maybe 4 days total. If we use this process AND use your suggestions to not 
>commit
> huge chunks of untested code during our 'stabilization period' I am confident we can 
>get
> stable releases out on almost every try. We can control the release of tarballs to 
>the
> test community.
> 
> And what is the point of having testers spend time on a release that we know is 
>broken?
> Isn't it better to just tell them "hey don't waste your time on this tarball"?.  
>OTOH...
> what rule says that testers must test each and every tarball? If a tarball (even an 
>alpha
> tarball) works well enough, the testers can still find and report bugs that we havent
> discovered yet.
> 
> One other question... have you received complaints from testers about the frequencey 
>of
> our tarball updates?

Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;)



> I don't think we are currently using the model suggested by Roy. I believe Roy's 
>model is
> closer to what Cliff and I are advocating. With one exception... The exception is 
>that
> some of us believe a 'feature freeze' (or 'big code change freeze', whatever you 
>want to
> call it) needs to go into effect during the 'stabilizing period'.  I know Roy 
>doesn't like
> this idea but I see no other way out of our current inability to get stable releases.

There is no such need.  Tag.  Roll in or out the changes that get a particular version
stable.  We have CVS.  Use it.



> > Yep.  :-)  But we also need to stop committing every possible change immediately.
> 
> +1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) 
>big
> commits during the period that do not enhance stability.

My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure 
build maintenance by platform maintainers) on a tagged branch.  There's no need for 
this
in the main tree.

See my post to rbb for the rest of my thoughts on this personal slight, 
you are certainly impliciated as well.

Bill

Re: make distclean doesn't

[William A. Rowe, Jr.]

From: "Pablo Chepalich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 12:26 PM
Subject: RE: make distclean doesn't


> how can I do to unsuscribe??
> thanks

read the message header (message properies - details - view source)

it provides the directions.

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 8:57 AM

> On Thursday 30 August 2001 06:38, Bill Stoddard wrote:

> > Completely agree that our release strategy (with Dr. Evil quotes around
> > strategy) is broken.  But we should be able to tag the tree anytime, IMHO.
> > If HEAD is good, I am for tagging 2.0.26 and testing it but let's not roll
> > the tarball. Fix any problems in 2.0.26 and bump the tag on affected files.
> > When we are satisfied, roll 2.0.26. Put a time limit on the whole process
> > of say, 4 days. If the time limit is exceeded (showstopper problems have
> > not been driven out within 4 days of the tag) or the rolled tarball has
> > showstoppers, consider the beta effort a failure and move on.

I'd say scope, over time.  If two platforms are 'touchy' about the build, and there
is a three line patch to get those to build, then we do it.  If there is a segfault
we can close (say J. Trawick's fix of my oops last night) then we close it.

I'm going to suggest a simple, absolute rule.  If a .h file changes (even a generated
one) then the tag is deep six-ed.  If the httpd-std.conf file changes, it's axed.  
And if the syntax parsers change, it's axed.  Anything in between is our call.

I'm going to suggest we branch every release as APACHE_2_0_nn once we apply any patch
out-of-sequence (from HEAD).  E.g., I commit a feature after HTTP_2_0_30 is tagged.
Then someone notices a rare segfault dating to 2.0.12.  Well, That patch goes in, but
if it needs to be dropped on HTTP_2_0_30, then we branch with the original 
APACHE_2_0_nn
tag.  Anyone who checks out from cvs co -r APACHE_2_0_nn has the authoritative, current
candidate.

And I suggest we go to r-t-c on following any tag.  I'm not suggesting r-t-c on the
main branch, since there aren't enough people following some obscure aspects of the
server to comment (in a timely manner.)  But once it's tagged - 3 +1's before patching
(or even bumping) a tag!

> > This is basically what we did with 2.0.24 and it was almost successful.
> > 2.0.24 dragged on a bit too long (over a week) and we rolled a couple of
> > different 2.0.24 tarballs, which was not cool. Tagging a good HEAD,
> > incrementally fixing showstoppers (provided the fixes are relatively
> > limited in scope and simple) and bumping the tag on affected files, and
> > exercising a little disipline and restraint for a few days (even just a few
> > hours) prior to our target for rolling a beta would go a long way to
> > solving this problem.
> 
> And it would go a long way towards pissing off our testers.  We have people
> who download the tarball when we release it, and if we replace that tarball
> after just a few hours, then we are basically telling them that we don't need
> their input, and they are only useful if they actually follow new-httpd, which
> I think we all know is INCREDIBLY hard to do most days.

Ryan, how many testers lists do we have?  dev@httpd is _NOT_ the tarball test list.
The order must go 

  1. Tag.  Announce as version candidate at [EMAIL PROTECTED]
  2. wait for folks to build and regress (24 hours???)
  3. vote.  Is the feedback [at least] alpha quality?  Are there no beta showstoppers?
  4. bump subrevision to -alpha [optional - but I think we need to go here]
  5. Tar.  Announce as beta candidate at [EMAIL PROTECTED]
  6. wait for folks to build, regress, and stress (72 hours???)
  7. vote.  Is the feedback [at least] beta quality?  Are there no release 
showstoppers?
  8. bump subrevision to -beta [optional - but I think we need to go here]
  9. Tar.  Announce as release candidate at [EMAIL PROTECTED]
 10. wait for folks to build, regress, and further stress (one week???).  
 11. The Adventuous may experiment with installing to production on non-critical 
servers.
 12. vote.  Is the feedback of release quality?  Are there no new showstoppers?
 14. bump subrevision to -gold.
 15. Tar.  Up to www.apache.org/dist/.  Broadcast the release 

There will be no changes to a -gold release, ever.  We could subversion the -alpha and
-beta versions, e.g. 2.0.25.-alpha.  I propose the number of days since the 
official
release of Apache 1.0 ;)

Take a page from the Jakarta project - their release schema works.

> tag and roll and test.  If that one isn't good enough, then we do it again a week
> later.  We would easily get to a beta or production release, if we didn't keep
> changing the internals of the server, or if we posted large patches before
> they were committed, or if people ran the httpd-test/perl-framework test suite
> before committing, and if people would write tests once they fix a bug.  The
> problem we have right now, is that most people don't use the test-suite, so
> even though it is catching most of the bugs when they are committed, nobody
> knows it.

Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike 
apache-1.3)
that is mildly difficult in some quarters.  I've specifically introduced the cygwin 

Fw: mod_log-any/8021: [PATCH] %b,%B in LogFormat not logged zero for HEAD request

[William A. Rowe, Jr.]

Would someone be willing to review, patch, and close this PR?

Bill

- Original Message - 
From: "Taketo Kabe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 5:31 AM
Subject: mod_log-any/8021: [PATCH] %b,%B in LogFormat not logged zero for HEAD request


> 
> >Number: 8021
> >Category:   mod_log-any
> >Synopsis:   [PATCH] %b,%B in LogFormat not logged zero for HEAD request
> >Confidential:   no
> >Severity:   non-critical
> >Priority:   medium
> >Responsible:apache
> >State:  open
> >Quarter:
> >Keywords:   
> >Date-Required:
> >Class:  sw-bug
> >Submitter-Id:   apache
> >Arrival-Date:   Fri Jul 13 03:40:05 PDT 2001
> >Closed-Date:
> >Last-Modified:
> >Originator: [EMAIL PROTECTED]
> >Release:2.0.20
> >Organization:
> apache
> >Environment:
> 
> SunOS 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-60
> gcc version 2.95.2 19991024 (release)
> ./configure [--enable-log-config]
> 
> >Description:
> 
> The "%b" "%B" directives in LogFormat should indicate "-" or "0" for
> HEAD requests, because no response body is sent --
> but actually, the file size is logged.
> 
> This was because r->sent_bodyct flag, which tells logger to 
> log r->bytes_sent, is set to 1 BEFORE checking & discarding the body in 
> modules/http/http_protocol.c:ap_http_header_filter() .
> 
> Setting r->sent_bodyct AFTER checking for HEAD fixed it.
> 
> >How-To-Repeat:
> 
> * Setup a LogFormat with "%b" or "%B" within 
>   (the default combined log is enough)
> * Issue a HEAD request for a plain file.
> * Examine the access_log.
>   The 7th field (bytes transmitted) should be "-" or "0",
>   but actually is the size of the file.
> 
> >Fix:
> 
> #
> #** modules/http/http_protocol.c HEAD logs full content bytes
> #
> # This patch fixes that "%b" "%B" (bytes sent, excluding response headers)
> # directives for mod_log_config, is logged as full file size (should be zero).
> #
> ##find httpd-2_0_20 -name '*.dist7' -exec ./0diff {} \;
> /usr/local/gnu/bin/patch -p1 --backup --suffix=.dist7 << 'EOP'
> === {
> diff -u httpd-2_0_20/modules/http/http_protocol.c.dist7 
>httpd-2_0_20/modules/http/http_protocol.c
> --- httpd-2_0_20/modules/http/http_protocol.c.dist7 Fri Jul 13 07:32:53 2001
> +++ httpd-2_0_20/modules/http/http_protocol.c Fri Jul 13 07:37:42 2001
> @@ -1206,14 +1206,14 @@
>  
>  terminate_header(b2);
>  
> -r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
> -
>  ap_pass_brigade(f->next, b2);
>  
>  if (r->header_only) {
>  apr_brigade_destroy(b);
>  return OK;
>  }
> +
> +r->sent_bodyct = 1; /* Whatever follows is real body stuff... */
>  
>  if (r->chunked) {
>  /* We can't add this filter until we have already sent the headers.
> === }}
> EOP
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
>  [In order for any reply to be added to the PR database, you need]
>  [to include <[EMAIL PROTECTED]> in the Cc line and make sure the]
>  [subject line starts with the report component and number, with ]
>  [or without any 'Re:' prefixes (such as "general/1098:" or  ]
>  ["Re: general/1098:").  If the subject doesn't match this   ]
>  [pattern, your message will be misfiled and ignored.  The   ]
>  ["apbugs" address is not added to the Cc line of messages from  ]
>  [the database automatically because of the potential for mail   ]
>  [loops.  If you do not include this Cc, your reply may be ig-   ]
>  [nored unless you are responding to an explicit request from a  ]
>  [developer.  Reply only with text; DO NOT SEND ATTACHMENTS! ]
>  
>  
> 
> 

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 2:17 PM

> > Certainly converting mod_mime
> > to a hash makes the other key whiner of "we've got to get this out the door" look
> > equally foolish.  That patch ate a week of several people's lives.  I hope the
> > performance improvement proves worth it.
> 
> Heh, heh. You already know the answer to that question.  If there are still problems 
>with
> the hash, I would vote to revert back to tables. A little performance boost is nice 
>but
> not at the expense of reasonable simplicity.

Problems?  Of course not (anymore).  Of course nobody but Brian Pane has commented on 
the 
optimization schema to avoid merges of all sorts without introducing conf->pool 
corruption.

Message-ID: <00d301c125ea$ea541b00$[EMAIL PROTECTED]>
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Optimizing dir_merge()
Date: Wed, 15 Aug 2001 19:28:31 -0500

and it's suppliment

Message-ID: <02a601c125f3$f152a350$[EMAIL PROTECTED]>
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <00d301c125ea$ea541b00$[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Subject: Re: Optimizing dir_merge()
Date: Wed, 15 Aug 2001 20:36:08 -0500

this schema helps any module be a good citizen in Apache performance, if we adopt these
guidelines.  The entire server should pick up a good bit.

Bill - want a fun one line patch?  Go find the expand hash fn, and change the hash
size growth from (last_element * 2 + 1) to ((last_element + 1) * 4 - 1)

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 1:03 PM


> > > At least on this front, I'm in total agreement... the httpd-test suite is
> > > excellent.  I've gotten to where I rely on it heavily to test any change I
> > > make (even small ones) before committing, because it's so good at sniffing
> > > out the subtle (and not-so-subtle) problems.  If everybody used it, we'd
> > > be set.
> 
> Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike 
>apache-1.3)
> that is mildly difficult in some quarters.  I've specifically introduced the cygwin 
>support 
> to allow me to build httpd-test.  We will see how this goes.

Well, just so those of you on cygwin are aware, it seems that there is a bit more work
todo before cygwin will work with httpd-test (although it serves pages by simply 
commenting
out the user and group directives.  I suspect that's the problem with the test 
framework,
as well.)  I'm jumping over to Doug's suggestion to customize the code just a bit for 
win32
native, as long as I have to do the work.  If anyone wants to play in cygwin, just 
check out
httpd-test from CVS, and go to town :)


> I'm asking key architechture questions to the list, and only about three of us are 
>even
> participating in that discussion.  As long as that's true, I don't expect a release 
> this year unless I follow c-t-r to underlying opportunities for future exploits to 
>appear.
   ^^
s/I/we/  fix the

if it wasn't obvious in spite the total lack of grammer, and this doesn't just go for 
me ;)

There are enough others working dilligently in their corners of the code to get those
parts right - code I certainly don't grok (nor expect to.)  Thanks esp. Jeff, Ryan, 
Graham,
and the handful of others for touching new emits or breakage from my sometimes sloppy 
incremental application of these patches.  I'm doing what I can to move or touch one 
bit
at a time so the commits are more easily reviewed; my layering is sometimes hazerdous.

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Brian Pane" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 3:09 PM


> What's not clear, however, is how much of a speedup we're getting from all
> the subsequent enhancements to avoid copying in the same-pool case (which is
> where all the real complexity is).  Anybody have benchmark or profile data
> on this part?

We still copy in this case.  You would need to experiment, per the short writeup
I did, by modifying any module that does a table_merge or table_overlap or some
hash merge.  If you could post such numbers, perhaps that would get some further
scrutiny from members of the list.

Bill

Re: 2.0.26?]

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 6:34 PM


> From: "Ian Holsman" <[EMAIL PROTECTED]>
> Sent: Thursday, August 30, 2001 5:42 PM
> > 
> > the only thing 'funny' I'm noticing is that the map_to_storage hook
> > isn't getting called for a sub-request.. this may be my code
> > I just noticed that 10 minutes ago,
> > I'm still investigating it.
> 
> That would be a problem.  It doesn't surprize me either.  Every month I go back over 
>the
> discrepancies in the internal_internal_redirect v.s. ap_process_request v.s. all the
> other ways we set up redirects/subrequests.
> 
> These distinctions have to go away.  Not that the steps can't be _heavily_ optimized
> by looking at r->prev or r->main for clues, but we need a single code path through
> this potentially tricky code.
> 
> Notice all the fooness in the subreq mechanisms "Hey, if this, then we don't need to
> do that!"  All well and good until some module gets hurt ;)  If the authn/authz 
>module
> _itself_ peeked at the pool data for r->main->p, "my_own_cache" and sees it's being
> redundant, it pulls a fast exit (fast OK, fast DECLINED, or fast 
>HTTP_NOT_AUTHORIZED.)
> 
> There is probably another weeks worth of work in optimizing these modules (see the
> ap_location_walk function for such an example.)  Then all these code paths can be 
>folded
> into a single place.

The other option is that we patch these to a single code path _today_.  Let Apache run 
a
bit slow until these optimizations are moved into the right, magic places.

Thoughts?

Bill

Re: 2.0.26?

[William A. Rowe, Jr.]

Ill get the subreq fix in in the next 45 minutes - let's see what disappears.

- Original Message - 
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 7:32 PM
Subject: Re: 2.0.26?


> 
> What's with this?
> 
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> ---
> modules/cgi.t36   31  86.11%  1-4, 6, 8-25, 29-36
> modules/info.t11 100.00%  1
> modules/vhost_a   88 100.00%  1-8
> 
> 
> I'm currently getting lots of "Use of uninitialized value" warnings from
> the test harness, so I don't know if this is the tests being broken or the
> httpd being broken or both.  Anyone else seeing this on HEAD?
> 
> Thanks,
> Cliff
> 
> 
> --
>Cliff Woolley
>[EMAIL PROTECTED]
>Charlottesville, VA
> 
> 
> 

Re: 2.0.26?

[William A. Rowe, Jr.]

Unless I made a fatal flaw, this should be it... lets get testing/auditing, folks ;)

I had to move the ap_die/decl_die/finalize_request_protocol from 
ap_process_request_internal
to make it truly portable.  Really a straightfoward change, if I've done it right.
I'll caution I'm a bit tired tonight, so we need to be cautious.

Cliff - you are set up with the test bench :-?

Bill

- Original Message - 
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 7:49 PM
Subject: Re: 2.0.26?


> Ill get the subreq fix in in the next 45 minutes - let's see what disappears.
> 
> - Original Message - 
> From: "Cliff Woolley" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, August 30, 2001 7:32 PM
> Subject: Re: 2.0.26?
> 
> 
> > 
> > What's with this?
> > 
> > Failed Test  Status Wstat Total Fail  Failed  List of failed
> > ---
> > modules/cgi.t36   31  86.11%  1-4, 6, 8-25, 29-36
> > modules/info.t11 100.00%  1
> > modules/vhost_a   88 100.00%  1-8
> > 
> > 
> > I'm currently getting lots of "Use of uninitialized value" warnings from
> > the test harness, so I don't know if this is the tests being broken or the
> > httpd being broken or both.  Anyone else seeing this on HEAD?
> > 
> > Thanks,
> > Cliff
> > 
> > 
> > --
> >Cliff Woolley
> >[EMAIL PROTECTED]
> >Charlottesville, VA
> > 
> > 
> > 
> 
> 

Re: cvs commit: httpd-2.0/server request.c

[William A. Rowe, Jr.]

From: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 8:50 PM


>   Modified:server   request.c
>   Log:
>   Normalize all paths to run the same, common code for pre-request setup
>   from the primary request, redirects and sub-requests.
>   
>   This will significantly reduce opporunities for inconsistancy (such
>   as Ian observed, and as I repaired only a month ago.)
>   
>   This promotes process_request_internal to an ap_ namespace protected
>   entity in server/request.c (from it's old home in http/http_request.c)
>   since this fn has no http specifics.
>   
>   Reviewed (in concept): Cliff Woolley, Ian Holsman
>   
>   Revision  ChangesPath
>   1.39  +158 -66   httpd-2.0/server/request.c
>   
>   +AP_DECLARE(int) ap_process_request_internal(request_rec *r)
...
>   +if ((access_status = ap_run_fixups(r)) != 0) {
>   +return access_status;
>   +}
>   +
>   +/* The new insert_filter stage makes sense here IMHO.  We are sure that
>   + * we are going to run the request now, so we may as well insert filters
>   + * if any are available.  Since the goal of this phase is to allow all
>   + * modules to insert a filter if they want to, this filter returns
>   + * void.  I just can't see any way that this filter can reasonably
>   + * fail, either your modules inserts something or it doesn't.  rbb
>   + */
>   +ap_run_insert_filter(r);

Right here is a significant change.  I don't know that it's wrong.

If a subrequest is text/plain, and the parent request is text/html - isn't a text->html
converter appropriate here?

This places a burden on a filter author (or user, yuck!) to note that this is a 
subrequest.

I don't know that I like this - let's see what the tests reveal.

>   +if ((access_status = ap_invoke_handler(r)) != 0) {
>   +return access_status;
>   +}
>   +
>   +return OK;
>   +}
>   +
>   +
...   
>   @@ -1592,7 +1684,7 @@
>{
>int retval;
>
>   -/* see comments in process_request_internal() */
>   +/* see comments in ap_process_request_internal() */
>ap_run_insert_filter(r);
>retval = ap_invoke_handler(r);
>ap_finalize_sub_req_protocol(r);

WAIT ... this burden always exists.  It -appears- that we simply nix this 
ap_run_insert_filter
from ap_run_sub_req, and rely on this happening in ap_process_request_internal.

I like this better - it gives the sub_req invoker the chance to do _anything_ to the 
subrequest
they feel they should.

Comments?

Bill

Fw: [INFO] [CLA-2001:418] Conectiva Linux Security Announcement - openssl

[William A. Rowe, Jr.]

The following provides a very respectible detail of why we can't install Apache 2.0
mod_ssl with anything less than 0.9.6b.  Hope some of you find this interesting
or otherwise useful.

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> - --
> CONECTIVA LINUX SECURITY ANNOUNCEMENT 
> - --
> 
> PACKAGE   : openssl
> SUMMARY   : Several vulnerabilities in the OpenSSL library
> DATE  : 2001-08-30 16:11:00
> ID: CLA-2001:418
> RELEVANT
> RELEASES  : 4.0, 4.0es, 4.1, 4.2, 5.0, prg graficos, ecommerce, 5.1, 6.0, 7.0
> 
> - -
> 
> DESCRIPTION
>  OpenSSL is a library providing several crypto and digital certificate
>  handling functions.
>  Several vulnerabilities have been addressed in newer versions of this
>  library:
>  1. OpenSSL now avoids using environment variables when running as
>  root;
>  2. The result of RSA-CRT is now checked to reduce the possibility of
>  deducing the private key from an incorrectly calculated signature;
>  3. Changes to prevent Bleichenbacher's DSA attack;
>  4. OpenSSL now zeroes the premaster secret after deriving the master
>  secret in DH ciphersuites;
>  5. Fix for a vulnerability in the pseudo random number generator
>  which allowed an attacker to predict the internal state of the PRNG
>  and thus predict future PRNG output.
>  The first four vulnerabilities have been addressed in the 0.9.6a
>  version of the library and affect Conectiva Linux <= 6.0 only, while
>  the last one was fixed with the 0.9.6b release and affects Conectiva
>  Linux 7.0 and earlier.
>  The packages available through this update have been patched to fix
>  all these vulnerabilities. Thanks to the OpenSSL team for releasing
>  the new versions and to Nalin Dahyabhai from Redhat for providing
>  patches for older versions.
> 
> 
> SOLUTION
>  All users should upgrade the OpenSSL library. After the update,
>  programs which use the library, such as apache and openssh, should be
>  restarted.
>  
>  IMPORTANT: updated packages for Conectiva Linux 4.0 and 4.0es are not
>  yet available.
>  
>  
>  REFERENCES
>  1. http://www.securityfocus.com/bid/3004
>  2. http://www.openssl.org
>  3.http://marc.theaimsgroup.com/?l=openssl-announce&m=98655255404174&w=2
> 
> 
> DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES
> ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/openssl-0.9.5a-2U41_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/4.1/i386/openssl-devel-0.9.5a-2U41_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/4.1/i386/openssl-0.9.5a-2U41_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/openssl-0.9.5a-2U42_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/4.2/i386/openssl-devel-0.9.5a-2U42_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/4.2/i386/openssl-0.9.5a-2U42_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/5.0/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/5.0/i386/openssl-0.9.5a-2U50_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/openssl-0.9.5a-2U51_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/5.1/i386/openssl-0.9.5a-2U51_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/5.1/i386/openssl-devel-0.9.5a-2U51_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/openssl-0.9.6-4U60_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/6.0/RPMS/openssl-0.9.6-4U60_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/6.0/RPMS/openssl-devel-0.9.6-4U60_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/openssl-0.9.6a-3U70_1cl.src.rpm
> ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-doc-0.9.6a-3U70_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-devel-0.9.6a-3U70_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-0.9.6a-3U70_1cl.i386.rpm
> 
>ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-devel-static-0.9.6a-3U70_1cl.i386.rpm
> ftp://atualizacoes.conectiva.com.br/7.0/RPMS/openssl-progs-0.9.6a-3U70_1cl.i386.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/openssl-0.9.5a-2U50_1cl.i386.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/SRPMS/openssl-0.9.5a-2U50_1cl.src.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/openssl-devel-0.9.5a-2U50_1cl.i386.rpm
> 
>ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/openssl-0.9.5a-2U50_1cl.i386.rpm
> 
> 
> ADDITIONAL INSTRUCTIONS
>  Users of Conectiva Linux version 6.0 or higher may use apt to perform 
>  upgrades of RPM packages:
>  - add the following line to /etc/

Re: cvs commit: httpd-2.0/include ap_release.h

[William A. Rowe, Jr.]

From: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 11:01 PM


> jwoolley01/08/30 21:01:19
> 
>   Modified:include  ap_release.h
>   Log:
>   Ryan apparently bumped this back DOWN from 2.0.25 to 2.0.25-dev after the
>   last tag, rather than UP to 2.0.26-dev.  =-)

I know there was a reason I thought it odd that you were planning to roll the
2.0.26 version (perhaps since I wasn't coding on 2.0.26-dev :-)


The URI processing is still borked, somewhere, when I request http://theserver/.  
I'm hunting this down right now.

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Cliff Woolley" <[EMAIL PROTECTED]>
Cc: "William Rowe" <[EMAIL PROTECTED]>


> On Thu, 30 Aug 2001, Cliff Woolley wrote:
> 
> > I was just running the tests from httpd-test (which seems to now be
> > working) in order to post the results here (they were failing miserably),
> > but I see that you just committed a fix.  I'll stop my test and do a cvs
> > up.  Stay tuned...
> 
> It's a helluva lot closer than I've seen it all day I think.  That last
> fix definitely helped a LOT.  Right now everything seems good except
> mod_include:

Your segfaults prove that up.  Something is wrong in URI assignment, I haven't
figured exactly where, but I'm certain it's in the subreq #if 0 /* XXX */'d code.

Gut instinct?  The "INTERNAL FOONESS" uri's which are now going through 
walk, we have to think those through.

> One harmless, unrelated warning during the compile which resulted from the
> #if 0's you added:
> 
> request.c:297: warning: `resolve_symlink' defined but not used

That will become used, rather soon (after the next tag.)

Re: 2.0.26?

[William A. Rowe, Jr.]

From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 11:38 PM


> On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
> 
> > Gut instinct?  The "INTERNAL FOONESS" uri's which are now going
> > through  walk, we have to think those through.
> 
> You're right:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 20591)]
> ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative req")
> at util.c:488
> 488 name[w++] = name[l++];
> (gdb) bt
> #0  ap_getparents (name=0x80e0420 "INTERNALLY GENERATED file-relative
> req")
> at util.c:488
> #1  0x080e0420 in core_cmds () at eval.c:41
> #2  0x080b9912 in ap_process_request_internal (r=0x8159acc) at
> request.c:152
> #3  0x080bacf4 in ap_sub_req_lookup_file (new_file=0xbfffaf50 "if4.shtml",
> r=0x8155aac, next_filter=0x8156c34) at request.c:1672


I suggest we handle this as follows; r->uri becomes NULL.  If a hook fn doesn't
like it, it needs to decline.  Where we go an reject the URI out of hand, let's
also test for r->main, and if we have a parent, then let it slide.  If we don't
(we are the main request) we can cough up a 500 if there was a leading slash
or asterisk on the original uri, or a 400 if there was not.

I've had it (for tonight.)  I'll be happy to pick back up anything necessary in
the morning, and will finish my audit of the overall delta after we pin this
down.  But I would much rather see non-file requests get r->filename of NULL
(what about mime filename extensions?  I don't think they should apply to 
non-files) and r->uri of NULL for truly bogus internal redirects.

I know this will break some 3rd party modules.  This is 2.0, and we are working
to _help_ them avoid the bugtrac reports on their modules.  I'd think getting 
this right (in this day and age of the hourly new exploit) is far perferable to
inconviencing an author with a set of five new rules.  {Ok ok... this will get
documented once decisions are reached!}

Bill 

Re: mod_rewrite & SCRIPT_URx envvars

[William A. Rowe, Jr.]

From: "Robert Simonson" <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 10:45 AM


This doesn't seem right...

RewriteEngine Off
   ...
   
 RewriteEngine On
 ...
   

If I serve something from this directory container, the SCRIPT_URx
environment
variables are not set because the main server config has the engine off.
Is this right?  It seems like we should be setting them for the context in
which the engine is turned on.

Rob Simonson
[EMAIL PROTECTED]


That's a bug - iif your request is _really_ for a file in /some/directory
(or its subdirectories.)

If your request is for a proxy, or some other abstract entity, you may no
longer hit Directory/File sections.  E.g. proxy directives can no longer go
into a  block - they must appear in a  block.

Bill

Re: core dump when merging directory configs

[William A. Rowe, Jr.]

The problem is this ...

sub_req (and perhaps redirect - I'm checking) don't set up the server/vhost
per_dir_config so ap_location_walk starts with a NULL r->per_dir_config pointer.

Since there _is_ a merge, and LHS is NULL, the request dies in the core default
(fallback) dir_merge.

I need to contemplate this for a bit, likely to patch it in about an hour.

Bill

From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 1:30 PM
Subject: Re: core dump when merging directory configs


> On 31 Aug 2001, Ian Holsman wrote:
> 
> > Ok.
> > I narrowed this down abit.
> > current CVS head
> >
> > with a config with a section in my httpd.conf like:
> >
> > 
> > 
> > (it can have stuff inside of the location directive)
> >
> >
> > If I do a GET /test/index.html it works
> > if I do a GET /test/ it core dumps
> > any ideas?
> 
> I was just looking at exactly the same thing.  It's unrelated to the
> INTERNALLY GENERATED FOONESS thing.  I'll keep looking...
> 
> --Cliff
> 
> --
>Cliff Woolley
>[EMAIL PROTECTED]
>Charlottesville, VA
> 
> 
> 

Re: core dump when merging directory configs

[William A. Rowe, Jr.]

Simpler example...




Request /icons/

I'm debugging now.

- Original Message - 
From: "Ian Holsman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 1:26 PM
Subject: core dump when merging directory configs


Ok.
I narrowed this down abit. 
current CVS head

with a config with a section in my httpd.conf like:



(it can have stuff inside of the location directive)


If I do a GET /test/index.html it works
if I do a GET /test/ it core dumps
any ideas?

--backtrace--

#0  0x08079721 in ap_merge_per_dir_configs (p=0x80f6294, base=0x0,
new_conf=0x810b40c) at config.c:264
264 conf_vector[i] = new_vector[i] ? new_vector[i] :
base_vector[i];
(gdb) bt
#0  0x08079721 in ap_merge_per_dir_configs (p=0x80f6294, base=0x0,
new_conf=0x810b40c) at config.c:264
#1  0x0808bf36 in ap_location_walk (r=0x80f62c4) at request.c:1208
#2  0x0808b251 in ap_process_request_internal (r=0x80f62c4) at
request.c:154
#3  0x0808c425 in ap_sub_req_lookup_dirent (dirent=0xbfffd5b0,
r=0x80f22a4, next_filter=0x0) at request.c:1524
#4  0x0806d261 in make_autoindex_entry (dirent=0xbfffd5b0,
autoindex_opts=10240, d=0x80acad4, r=0x80f22a4, keyid=78 'N',
direction=65 'A', pattern=0x0) at mod_autoindex.c:1260
#5  0x0806ec14 in index_directory (r=0x80f22a4,
autoindex_conf=0x80acad4) at mod_autoindex.c:1953
#6  0x0806ee07 in handle_autoindex (r=0x80f22a4) at mod_autoindex.c:2015
#7  0x080793b4 in ap_run_handler (r=0x80f22a4) at config.c:185
#8  0x080798de in ap_invoke_handler (r=0x80f22a4) at config.c:344
#9  0x0806a34a in ap_process_request (r=0x80f22a4) at http_request.c:286
#10 0x0806610e in ap_process_http_connection (c=0x80f0364) at
http_core.c:287
#11 0x0808209c in ap_run_process_connection (c=0x80f0364) at
connection.c:82
#12 0x08082231 in ap_process_connection (c=0x80f0364) at
connection.c:219
#13 0x08077f9c in child_main (child_num_arg=1) at prefork.c:829
#14 0x080780e9 in make_child (s=0x80abb04, slot=1) at prefork.c:916
#15 0x0807815f in startup_children (number_to_start=5) at prefork.c:939
#16 0x080785a3 in ap_mpm_run (_pconf=0x80aac04, plog=0x80dcd94,
s=0x80abb04) at prefork.c:1155
#17 0x0807d6d1 in main (argc=1, argv=0xb934) at main.c:431
#18 0x401942ae in __libc_start_main (main=0x807d1a0 , argc=1,
ubp_av=0xb934, init=0x805c5e4 <_init>,
fini=0x80932e0 <_fini>, rtld_fini=0x4000cf28 <_dl_fini>,
stack_end=0xb92c) at ../sysdeps/generic/libc-start.c:129
(gdb) quit


-- 
Ian Holsman  [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608

Re: [PATCH] RE: make distclean doesn't

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 9:30 PM


> On Fri, Aug 31, 2001 at 03:02:32PM -0700, Ryan Bloom wrote:
> >...
> > exports.c shouldn't be cleaned, correct, because it is a part of the
> > distribution, or at least it should be if it isn't already.  config.nice is
> > not a part of the distribution however, and should be removed by
> > make distclean.
> 
> -1 on *any* form of clean that tosses config.nice
> 
> That holds *my* information about how I repeatedly configure Apache. That is
> a file that I use, and is outside of the scope of the config/build/whatever
> processes. Its entire existence is to retain the information. Cleaning it is
> not right.

What are you talking about?  We are talking about cleaning for packaging to
_other_ computers, not yours.  That's what rbb is speaking of by 'distclean',
clean enough for redistribution.

Bill

Win32 (OS2) /cgi-bin/ exe and bat experiment and observations

[William A. Rowe, Jr.]

I was playing with the script-aliased container.  I've removed two odder
aspects of the server behavior.  One, on Win32/OS2 mod_cgi would look for
a file of the requested filename + '.exe' tacked on.  That was (as the 
note said) somewhat bogus, and we have a feature to allow it, so I recently 
removed it.

The second, we can't multimatch just because we have a handler.  If they
don't ask for a given document (script.pl) we shouldn't serve for the handler
(cgi-script).  Only negotiation variables should be wildcard matched.
Of course, we deal with script.pl.en and script.pl.fr for script.pl just fine 
today, those are language (content) negotated.

So I experimented with the following to prevent the "Do you want to download
this Program" message in IE, when requesting a script (thirtytwo.exe).
I wanted to grab the script as a multimatch, so here's what I tried;


AllowOverride None
Options Multiviews<<< note multiviews
Order allow,deny
Allow from all
AddType text/plain .exe  <<< serve up as wildcards
AddType text/plain .bat


Here's what thirtytwo.exe (an html cgi) serves up.

HEAD /cgi-bin/thirtytwo HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 01 Sep 2001 06:25:31 GMT
Server: Apache/2.0.26-dev (Win32)
Content-Location: thirtytwo.exe
TCN: choice
Vary: negotiate
Connection: close
Content-Type: text/html; charset=ISO-8859-1

So the test essentially worked.  It also sends back text/plain as the
default, until the script itself sets the headers via util_script.c
parsing.  The text/plain .bat file worked as well.

Of course, docs/cgi-examples/test-cgi.bat offers another example of using the 
bogus mime header format to tell IE that text/plain content is to be shown, 
not run.  But notice that even that *must* strip off the extention.

So this is a rather cool option, I believe.  However, it doesn't quite work
at this moment, since the redirect/subreq mechanisms all strip of the query
args and POST stuff :(  Need to finish thinking through that aspect.

Trying the same with the 16 bit .exe, I get this 500 response

couldn't create child process: 22505: C:/Apache2/cgi-bin/SIXTEEN.EXE  :(

So we are obviously not dealing yet with older 16 bit exe's in apr.  This
may following with the Win9x port in general and cgi's (Win9x .bat files are
run by the *16* bit command shell!)

Just two cents for the night.  Need to get this documented - I'll flag my own
message to follow up, and take care of it within two weeks or so if nobody else 
on docs beats me to it ;)  I'll start patching next weekend - this is my weekend
to play CATCHUP (and I'm not talking about bugs)!

Bill

Re: 2.0.25 Problem with SSI

[William A. Rowe, Jr.]

Tonight's tree?  Ugh.  Send it at the list - I'm sure we are doing -one-
too many steps with our security overhaul :(

- Original Message - 
From: "Jerry Baker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 2:06 AM
Subject: 2.0.25 Problem with SSI


> I have a script that does this on Windows 2000:
> 
> foreach (`tracert -h 20 $ip`) {
> chomp $_;
> print $_ . "";
> 
> }
> 
> If I include this in an SSI with "include virtual" Apache inserts the
> HTTP headers into the SSI document as well.
> 

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Pier Fumagalli" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 8:57 PM


> "Ryan Bloom" <[EMAIL PROTECTED]> wrote:
> > 
> > 3) I don't believe that we should be adding every possible module to the core
> > distribution.  I personally think we should leave the core as minimal as
> > possible, and only add more modules if they implement a part of the HTTP spec.
> 
> I can't say much, as I'm not a developer of HTTPD, but I tend to share the
> feeling with Ryan on this. In the light of the latest security warnings on
> Tomcat, adding a single feature (CGI execution), compromised our entire
> core... And as Chuck forwarded to the members, it might be worth reading
> this .
> 
> Adding features to the core, unless they're absolutely 100% safe and 100%
> needed is, IMVVVHO, not a very good idea...

I concur.  I'd also point out that the more thoroughly we can document the new
hooks architechture, and expose the apr/apr-util/libhttpd api to the third party
developers, the more secure their modules stand to be.

By instituting additional internal interlocks (e.g. the request must have the
dir_walk/file_walk success tag before the core handler will work) and a very
predictable schema, that is successfully optimized, module authors won't spend
as much time hacking 'around' the core, and we will all enjoy significantly fewer
new holes in 2.0.

Let's make 2.0 the most _predictable_ release ever, and everyone benefits :-)

Bill

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Jerry Baker" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 10:32 PM


> Ryan Bloom wrote:
> > 
> > You know what's really funny?  Every time this has been brought up before,
> > the Apache core has always said, if you want to have gzip'ed data, then
> > gzip it when you create the site.  That way, your computer doesn't have to
> > waste cycles while it is trying hard to serve requests.  I personally stand by
> > that statement.  If you want to use gzip, then zip your data before putting it
> > on-line.  That doesn't help generated pages, but perl can already do gzip, as
> > can PHP.
> 
> Gzip'ing html into files is a hopeless waste of disk space and clutter.
> That means for every file you have to have a gzipped and non-gzipped
> version for browsers that cannot handle it. Then you have to configure
> Apache to check for and serve the proper file to the proper browser. It
> makes Web page maintenance a severe PITA as you have to re-gzip a doc
> everytime it is modified and upload both files.

Interesting point for gzip authors in general ... if it won't save a second
network packet - it is _not_ worth it (think favicon.ico, icon.gif (or any
self-compressed format), or littleframeset.html).

Probably always need to set some 'threshhold' of 8kb (minimally) that the
webserver absolutely ignores, and some include or exclude list by mime type
to describe the value of further compression.  Even if the file is requested
to be gzip'ped, and it's targetted for the cache, set a flag at the end that
says "hey, I saved -2% on this file, don't let us do _that_ again!  File foo
shouldn't be cached", and then internally add foo to the excludes list for
any gzip filter.

Bill

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 10:50 PM


> On Saturday 01 September 2001 20:10, Cliff Woolley wrote:
> >
> > Perhaps modules distributed through official httpd subprojects are more
> > visible/more trusted, but we don't really know one way or the other on
> > that front yet.
>
> I can agree with this, but this is something we need to fix.  There are many
> ways to fix it.  Fixing modules.apache.org would be a very good first step.

++1, we want to _highlight_ our extra projects at http://httpd.apache.org/more/!
And perhaps provide some links from pages like manual/mod/index.html with a
"Not here?  Try the third-party modules, (registered by their authors) 
at http://modules.apache.org/"; for completeness.

> Putting every module into the core is NOT the answer to this problem.  IMNSHO,
> Apache should be a minamilistic web server.  If we don't need it in the core,
> it shouldn't be there.  Personally, I would remove mod_dav from the server too,
> because it doesn't implement part of RFC2616.

I was thinking about this.  We are discussing if /modules/proxy/ should be readded
to the core tree over at [EMAIL PROTECTED]  My observation there is that the
RFC for mod_proxy may be expanded outside of the http schema in the future.  We
already have adjunt Connection-Upgrade/tls over http extensions to that RFC.  This
argument will give us headaches until we decide some simple rules to add a module
as a core or sub project.

WebDAV isn't a 'done' protocol, and really started out as the WebDA protocol
(versioning deferred until we figure out how it should be described.)  I'm sure
it will grow.  mod_ssl isn't 'done' either, until we implement the Connection-Upgrade
schema.  Not only are some folks in the world bound _never_ to download it (as it
is in conflict with their own laws) but some folks in the world are prohibited by
the US from downloading it (the T5).  And it too is supplimented by the TLS RFCs.

One thorn in everyone's side was that mod_proxy implemented a HTTP/1.0 superset, 
although the rest of the server was essentially HTTP/1.1.

IMHO, if a modules is on a different standards track (or likely to be extended on
one) it should probably live in it's own subproject.

Who on the proxy team wants to wait for the core to bump a version "just because
proxy wants us to."  The proxy team finishes implementation of another extension,
they want to get an alpha/beta/release out the door!  If they implement another
proxy-protocol, they want to get that out the door (sftp anyone?)

How about one last example ;-?  Lets say SQL support is deemed 'important'.  An
httpd-sql subproject might implement several aaa modules, with some additional
support/ apps, to allow SQL stuff.  Then they get the hairbrained idea to .htaccess
as a SQL table (for performance.)  This project could grow (with a charter of
'extending httpd core file-based mechanisms through a generic SQL layer') as far
as they wanted to take it.

In a perfect world, apache-2.0.26-gold-core.tar.gz contains just the core.  Then
give the world apache-2.0.26-gold-all-gold-20010915.tar.gz with all _released_ 
subprojects effective 2001.09.15 rolled in!  The adventurous could try the
apache-2.0.26-gold-all-beta-20010915.tar.gz.  Finally, the looney (most folks
that follow this list) can grab apache-2.0.26-gold-all-alpha-20010915.tar.gz
for alpha releases of every module (probably a longer list, since some subprojects
at a given time likely haven't gone gold just yet.)

Subprojects would probably have an easier time with a user of the gold apache core
release, since the bugs are more likely to be _in_ their module, not somewhere
else.  Now we stand a (small) chance of keeping up.

Add some decent user support outside of the (sometime now hard-to-reach) nttp
support in comp.infosystems.www.servers. and these could be really useful.  With
a [EMAIL PROTECTED], [EMAIL PROTECTED], proxy-users... and actually
make that a really strong system, by using mod_mbox on http://httpd.apache.org/
to allow folks to browse those threads.  We must be one of the last strong projects
with _no_ user's list (what's up with that ;-?)

Subprojects shouldn't be our orphans.  The give small author groups well deserved
recognition.  They need to become our crowning jewels.

Bill

Re: [PATCH] RE: make distclean doesn't

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 3:22 AM


> I use distclean on my computer all the time. Along with extraclean. Neither
> of those targets should toss config.nice. *That* is what I mean.
> 
> To be clear: nothing in our build/config/whatever should remove config.nice

Then it goes into the tarball.  Is that what you intend?

> "Clean" rules are about cleaning out state that might affect a build in some
> way. So we toss object files, generate makefiles, the configure script,
> whatever. But config.nice doesn't fall into that camp because it is not a
> "stateful" file. It is for the user to rebuild what they had before.

Which means it has nothing to do with cleaning the tree to a distribution 
state (or state 'ready for distribution'.)

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 4:43 AM


> On Sat, Sep 01, 2001 at 07:50:19PM -0700, Ryan Bloom wrote:
> > On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> > > On Sat, 1 Sep 2001, Ryan Bloom wrote:
> >...
> We ship code that uses it. zlib fixes their code (or somebody else fixes
> it). Now our module rocks. Chicken and egg... A ton of other projects use
> zlib. I see no reason for us to avoid it. If it *does* happen to have leaks,
> then (when somebody finds this to be true) they could fix it.

I kind of wonder about the 'leaks like a sieve' comments.  I wonder if the actual
users are the ones not following the API to cause zlib to clean up.

Let's not forget ... expat, pcre, and probably zlib have malloc/free fn ptrs in 
their code.  There is _nothing_ stoping us from using pools to initialize/mop up 
by thunking for their malloc/free fn ptrs into our pool architecture :)

> > > > 3)  I don't believe that we should be adding every possible module to
> > > > the core distribution.  I personally think we should leave the core as
> > > > minimal as possible, and only add more modules if they implement a
> > > > part of the HTTP spec.
> 
> The gzip content encoding is part of the HTTP spec. 

By implementation, or reference?  Sure Content-encoding is part of the spec, and
it's defined to allow authors to extend their support to any number of encodings,
and forces the server to use only what the client claims as supported encodings.

However, gzip is _defined_ by RFC, therefore we have a standards-based encoding
specification, which should be a requirement, IMHO, for inclusion in any ASF project.

> > > My personal opinion is that this one is important enough that it should go
> > > in.  Most clients support gzip transfer coding, and it's a very real
> > > solution to the problem of network bandwidth being the limiting factor on
> > > many heavily-loaded web servers and on thin-piped clients (read: modem
> 
> Agreed!

+1 with caviat to follow.

> But it isn't "invisible" if you do it with Perl, PHP, Python, or CGI. A
> person has to explicitly code it.
> 
> I'm really looking forward to mod_gz(ip) in Apache 2.0 so that Subversion
> can transfer its content in compressed form. All of that comes out of a
> database... it can't be precompressed, so that leaves a filter to do the job
> as it hits the wire. Doing large checkouts are almost *always* network bound
> rather than server/client bound. Compressing those files is a *huge* win.

So we need any gzip filter to drop out quick if 1. it knows this mime type should
not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the
uri/filename whatever in a list of exclusions (that could be automagically grown
when it hits files that _just_don't_compress_well_.

The fact that gzip doesn't _expand_ data is kind of nice.  But it still burns
CPU that we don't want to waste on useless tasks.

> > -1 (vote, not veto), for putting mod_gz in the core.
>
> Needless to say, I'm +1 on the concept. It's a big win for everybody. I
> haven't reviewed the code yet, so no commentary there.

I'm +1 on concept as well, provided we don't keep implementing resuable algorithms
in the core (those are definately apr-util style tasks), we might support both zlib
and zlibc (maybe thunk through apr-util?  I don't see a benefit just yet), and that 
we implement this legibly and simply in as few lines of code as possible.

If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/
instead of by reference.  It really isn't that large, and matches what we do today
with pcre and expat.  If we like, drop it into apr-util/encoding/unix/lib/zlib and
only expose it through thunks (allowing someone to come up with more robust or faster
apr-util thunks to source that we can _not_ redestribute.)  The more I contemplate,
the stronger my +1 for apr-util remapping, where appropriate on some platforms.

The gzip encoding isn't going to change anytime soon.  I'd say that makes it a core
candidate.  If someday later we add 'another' encoding, then that's a new module, and
mod_gzip can keep chugging away.  Or we implement this al la proxy.  mod_encoding for
the generic http encoding field parsing, and encoding_gzip for the backend.

Bill 

p.s. I believe this license is most _definately_ compatible with the ASF, see
http://www.gzip.org/zlib/zlib_license.html

Re: [PATCH] Add mod_gz to httpd-2.0

[William A. Rowe, Jr.]

From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 12:02 AM


> On 2001-09-01 at 20h50, possibly To [EMAIL PROTECTED] et al.,
> the keyboard of "Ryan Bloom" chattered:
> > 
> > Putting every module into the core is NOT the answer to this problem.
> 
> True.
> 
> > IMNSHO, Apache should be a minamilistic web server.
> 
> IMNSHO, strong disagreement.  It should be able to be configurable
> as minimalist, but that is *not* synonymous with shipping with a
> minimal set of modules.

http://www.zdnet.com/zdnn/stories/news/0,4586,2792860,00.html

Ken, I really _have_ to disagree with you on this count.

> > If we don't need it in the core, it shouldn't be there.
> 
> Again, strong disagreement.  Assuming that by 'core' you mean
> 'standard tarballs and install packages downloadable from apache.org.'

I share your objection Ken.  There is no reason _not_to_ bundle both the
minimalist and comprehensive tarballs (and label them as such.)

Re: cvs commit: httpd-2.0/modules/http mod_mime.c

[William A. Rowe, Jr.]

Thank you, first off, for catching my foobar.

But -1 on the solution.  This is contrary to the syntax of AddSomething.
AddSomething in mod_mime (and SetSomething in core) always _replaces_ the
prior declaration!!!

We are going to have 10,000,000 webserer users three years from now asking
why don't they successfully replace their filters!

The effects from multiple extensions may be cumulative (.shtml.gz, for example.)
The replacement of a given extension may not be.

We have to remain consistent.  I'll patch this Tuesday if you don't beat me to it.

Bill

From: <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 3:34 AM


> jerenkrantz01/09/02 01:34:45
> 
>   Modified:modules/http mod_mime.c
>   Log:
>   We should be copying the filters as well when we perform the extension merge
>   (which seems to use a ; syntax).
>   
>   Try:
>   AddOutputFilter GZ html  (server-level)
>   AddOutputFilter Includes html  (directory-level)
>   
>   Oops.
>   
>   Without this, when you use mod_gz and go to /foobarnotthere/, the error
>   page isn't handled by mod_include.  Oooops.
>   
>   Revision  ChangesPath
>   1.62  +18 -0 httpd-2.0/modules/http/mod_mime.c
>   
>   Index: mod_mime.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/modules/http/mod_mime.c,v
>   retrieving revision 1.61
>   retrieving revision 1.62
>   diff -u -r1.61 -r1.62
>   --- mod_mime.c 2001/08/30 04:11:57 1.61
>   +++ mod_mime.c 2001/09/02 08:34:45 1.62
>   @@ -191,6 +191,24 @@
>if (overlay_info->charset_type) {
>base_info->charset_type = overlay_info->charset_type;
>}
>   +if (overlay_info->input_filters) {
>   +/* We need to concat the filters */
>   +if (base_info->input_filters)
>   +base_info->input_filters = apr_pstrcat(p, 
>   +base_info->input_filters, ";", 
>   +overlay_info->input_filters, NULL);
>   +else
>   +base_info->input_filters = overlay_info->input_filters;
>   +}
>   +if (overlay_info->output_filters) {
>   +/* We need to concat the filters */
>   +if (base_info->output_filters)
>   +base_info->output_filters = apr_pstrcat(p, 
>   +   base_info->output_filters, ";", 
>   +   overlay_info->output_filters, NULL);
>   +else
>   +base_info->output_filters = overlay_info->output_filters;
>   +}
>}
>else {
>apr_hash_set(base, key, klen, overlay_info);
>   
>   
>   
>