Date: Fri, 7 Feb 1997 21:31:28 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@hyperreal.com
Subject: Re: updated Agenda for 1.2b7
In-Reply-To: <97020722300177@decus.org>
Message-ID: <Pine.BSF.3.95.970207211856.2047P-100000@alive.ampr.ab.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Fri, 7 Feb 1997, Rodent of Unusual Size wrote:

> >1.2b7 status as of Fri Feb  7 20:04:56 MST 1997:
> >
> >  * Committed since 1.2b6:
>     :
> >	* fix util_snprintf and unsigned ints on Alpha
>     :
> >  * 64-bit issues; general cleanup, ap_snprintf("%d", (int)-1) giving
> >    wrong behavior on Alpha boxes.
> 
>     Are there other 64-bit issues with snprintf?  Or was this the only
>     one?

I don't know of any other 64 bit issues with snprintf, but there are other
issues with the code on 64-bit platforms.  I think it is things like
assuming sizeof(*foo) = sizeof(int), etc.  Probably differs slightly
between platforms.

> 
> >  * directory_walk and relatives performance improvements
> >	<Pine.LNX.3.95dg2.970201140250.28944E-100000@twinlark.arctic.org>
> >	Dean submitted patch +1 Randy, Chuck
>     :
> >  * http_request.c: directory_walk() misses some <Directory ...> directives
> >    (PR#131).  I'm not sure the way things are done is really incorrect, 
> >    but should be looked at.
> 
>     Did the former have any [side-]effect on the latter?

Shouldn't.  I think Dean(?) has a seperate patch for the second one.

> 
> >  * user and server get confused over what should be a virtual host
> >	and what is the main server, resulting in access to something
> >	other than the name defined in the virtualhost directive (but
> >	with the same IP address) failing.  
> >		Status: should be looked at, may not be a nice way to fix 
> >			since it is likely not technically a bug.
> >
> >	New status: Dean posted patch, Ben +1-but-hasn't tested, may
> >		or may not be whole problem, Randy +1.
> 
>     Is this intertwined with the issue described by Alexei in
>     <Pine.HPP.3.95.970206111213.28200A-100000@ace.nueva.pvt.k12.ca.us>?
>     I.e., requests with no Host: header?

Sigh.  Perhaps.  I have not been able to look into it too much.  All I
know is that there are times when things appear to be defined as a virtual
host with an IP but Apache doesn't think they are.  Could be user error,
but...

> 
> >  * infinite loop in mod_imap due to parsing bug
> >		status: Marc found problem, wants input on which way to solve
> 
>     Um, what were the details on this?  I can't find your notes, Marc..

See PR#130.  The issue is how a base directory without a trailing / should
be treated.  I've included my original message below.  I think behavior 2
is probably better, but like 1 because it is easier to fix.  <g>  I am
planning on fixing it to work like 2 today or tomorrow.  I have not posted
the location of the problem code.

Original message:

Message-ID: <Pine.BSF.3.95.970127234333.11367L-100000@alive.ampr.ab.ca>

If you have a map file like:
        base foobar
        rect ../foo/bar.html 0,0 499,77

mod_imap will go into an infinite loop.  Fixing it isn't a problem and
I know exactly where to do what, but should the above lead to:

        1. foobar../foo/bar.html

or:
        2. foobar/../foo/bar.html

...which may end up being translated directly to foo/bar.html, but
that doesn't matter.

I don't use imagemaps much.  Does anyone actually use the first in
something like:

        base file
        rect 1.html 0,0 10,10
        rect 2.html 10,0 20,10

to get file1.html or file2.html?

Behavior 2 is more intuitive to most people I think, but they would
figure it pretty quickly if behavior 1 was used as long as their
server doesn't go into an infinite loop like it does now...