httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: pay attention now: old PRs to be cleaned up
Date Sat, 01 Nov 1997 21:47:53 GMT

On Fri, 31 Oct 1997, Marc Slemko wrote:

> To start off, a few PRs that need comments.  Some I'm just looking for
> agreement about closing.  Others volunteers to deal with them would be
> nice.  
> PR#258: ln -s foo.html
> 	Comment: doesn't seem to be any interest, should close?

close it... this can be done as a module.

> PR#505: proxy ftp does not work with anonftpd server by D. J. Bernstein
> 	Comment: a good little few minutes for someone to fix.  Not
> 	too involved.  Perhaps.

If you dig in you'll find a program
by djb which parses ftp listings from various servers/architectures.

> PR#557: ~UserHome directories are not honored in absolute pathname
> requests (.htaccess)
> 	I can agree with the concept of this patch.  This _is_
> 	annoying using userdir htaccess files on systems with bastard
> 	filesystems.  No comment on the supplied implementation
> 	though.

I tend to lean towards /home/userid/ always being valid, but that's just a
personal thing.  If I have multiple user filesystems I always set them up
with symlinks from /home/userid.  I don't think fixing this for one
directive is worth it, it needs to be fixed in general -- which means a
path expansion api. 

> PR#573: More LogFormat directives
> 	Something along these lines is really useful.  I would like to
>         be able to configure my logs to do something like
> 	"GET http://vhost/path/to/file HTTP/6.6" instead of just
>         /path/to/file. 
> 	In any case, being able to split these things up is a good thing.

Oh yeah there was another PR asking for a way to always print the IP
address in logs.  That's really useful because a reverse mapped IP is
useless in security situations.  Even if you have hostnames turned off, if
you have any mod_access protected areas you'll end up with some hostnames
resolved.  Granted those are guaranteed to be double-reversed, but suppose
someone sets up a double-reverse, hacks something, then removes the
double-reverse.  You'd really have no idea who did it... 


View raw message