pay attention now: old PRs to be cleaned up

[Marc Slemko <ma...@worldgate.com>]

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 http://www.somesite.org/foo.html foo.html

	Comment: doesn't seem to be any interest, should close?

PR#314:  Truncated (short/invalid) files are proxy-cached. Ought to be
invalidated.

	Martin: is this still an issue?  Can it be closed?

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.

PR#549: Missing HTTP_AUTHORIZATION in CGI environment

	See my patch and comments sent seperately.

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.

PR#558: except internal servers from ProxyRemote * http://myfirewall

	Looks like it could be a useful feature.  Not sure if
	this is the best way to implement it.  Someone could
	look at it.

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.

Re: pay attention now: old PRs to be cleaned up

[Dean Gaudet <dg...@arctic.org>]

On Sat, 1 Nov 1997, Alexei Kosut wrote:

> On Sat, 1 Nov 1997, Dean Gaudet wrote:
> 
> > 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. 
> 
> While /home/userid is nice, it doesn't work too well on a system with,
> say, 30,000 users, all of whom need home directories. This is why
> /home/u/s/userid style things were invented.

Yes, fine, my point is:  ~userid is not needed if the system is set up
with some predictable mapping from userid to homedir. 

> I think allowing ~userid expansion everywhere we allow filenames would
> be a good thing. If we just added this to os_canonical_filename(),
> would that be correct? ('course, it would mean that unix/os.c would
> have to get a real os_canonical_filename() function)

~expansions are slow, time them sometime on a system with 30k users.  To
make them work well we'd have to cache them all.  Which is a pain to do
properly ... so I return to my suggestion that the admins just make their
system more uniform. 

After all, they can fight with every program that needs a configurable
filename, or they can just admit defeat and build a directory hierarchy
that's manageable.

I'd be more inclined to accept some sort of relative filenaming
conventions.  Like filenames within a <Directory> or .htaccess can be
relative to the enclosing directory.  But this has problems, because you
don't typically want folks to "AuthFile .htpasswd" because that would mean
.htpasswd could be served.  But using tricks like "<Files .htpasswd>"
to deny access to it would break some things ... like the things I
turned into subrequests instead of plain pfopen()s because they needed
symlink protection.  The API needs two distinctions for file permissions
-- one meaning "file is valid for serving" and one meaning "file passes
minimal security tests such as device/fifo/socket/symlink stuff".

Dean

Re: pay attention now: old PRs to be cleaned up

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Sat, 1 Nov 1997, Dean Gaudet wrote:

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

While /home/userid is nice, it doesn't work too well on a system with,
say, 30,000 users, all of whom need home directories. This is why
/home/u/s/userid style things were invented.

I think allowing ~userid expansion everywhere we allow filenames would
be a good thing. If we just added this to os_canonical_filename(),
would that be correct? ('course, it would mean that unix/os.c would
have to get a real os_canonical_filename() function)

We'd probably have to add os_canonical_filename() to some places that
problably should have it anyway (e.g. the AuthFile directives, like
the PR is about), but I can see this being a useful thing. Even if we
didn't change that, "Alias /foo ~akosut/bar" could work.

P.S. Some words of advice to anyone considering purchasing Riven: If
you'd like to get any sort of work done in the next few weeks,
don't. It will suck you in, will twist your mind to work for it, you
will spend days and nights clicking and swapping CDs. You will become
consumed by this so-called "game."

P.P.S. Buy it anyway. It's worth it.

-- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>

Re: pay attention now: old PRs to be cleaned up

[Dean Gaudet <dg...@arctic.org>]

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 http://www.somesite.org/foo.html 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 koobera.math.uic.edu/pub/software 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... 

Dean