mod_negotiation.c 1.74

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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.

Re: mod_negotiation.c 1.74

[Jeff Trawick <tr...@attglobal.net>]

"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:

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

hmmm... we don't seem to get to the seek code with the stock
/htdocs/index.html.var.  Since I can't run mod_negotiation on Win32 I
spent some time making a test program which mimics the APR file
operations done by mod_negotiation; it must be incomplete because I
don't see any bad behavior with it on Win32.

> 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.

haven't tried yet

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: mod_negotiation.c 1.74

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

From: "Jeff Trawick" <tr...@attglobal.net>
Sent: Friday, August 24, 2001 8:00 AM


> Jeff Trawick <tr...@attglobal.net> writes:
> 
> > "William A. Rowe, Jr." <wr...@rowe-clan.net> 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: mod_negotiation.c 1.74

[Jeff Trawick <tr...@attglobal.net>]

Jeff Trawick <tr...@attglobal.net> writes:

> "William A. Rowe, Jr." <wr...@rowe-clan.net> 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 :)

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: mod_negotiation.c 1.74

[Jeff Trawick <tr...@attglobal.net>]

"William A. Rowe, Jr." <wr...@rowe-clan.net> 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.

I'll start playing with ungetc on buffered files :(
-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...