httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: [patch] 1.3.15 ap_os_is_path_absolute
Date Thu, 02 Nov 2000 03:17:35 GMT
> From: Brian Havard []
> Sent: Wednesday, November 01, 2000 8:39 PM
> >From: "William A. Rowe, Jr." <>
> >Sent: Wednesday, November 01, 2000 2:13 PM
> >
> >> Users are frequently reporting that their module/handler/alias
> >> absolute paths are being concatinated onto the server root.
> >> This is because 1.3.14 now refuses to believe in backslashes
> >> under win32, and it's up to the front end to deal with them.
> >> 
> >> Solution 3: My own - simply change both the ap_set_file_slot and 
> >> ap_server_root_relative functions pass the file arg through the
> >> ap_canonicalize_filename function before testing that it is/isn't
> >> absolute.  I'm +1, since it's a smaller, tighter patch.  It also
> >> helps third party authors and prevents them from thinking 
> >> about this issue entirely.
> >
> >Here's the patch... Brian, do you want to drop it in as-is and just
> >check out the behavior on OS2?
> Err, no. I'd much rather you used a more appropriate function [snip]

I don't want to pollute the 1.3.x namespace anymore than absolutely 
necessary :-)  We really should have no need for new functions anymore.

> Why are you so keen to use ap_os_canonical_filename() when you're not
> actually after a canonical file name?

Ah, but we are.  Canonical means (if I understand the general concept)
that it is something we can parse in proper form.  That doesn't mean a
specific os, nor does it mean just strip double slashes.  It means that
the name (aught to) be properly formatted for our server and the os to
both understand it.

ap_make_full_path() is the command you are thinking of, I believe.  It
performs (and states that it performs) exactly the behavior you assign 
to ap_os_canonical_filename().

> As for OS/2's ap_os_canonical_filename() being the only one to return
> absolute paths, I'd argue (again) that it's the only one that actually
> works.

Unix isn't working?

I really have no problem with the os fullpath function in OS2, provided
you at least are testing that it is an absolute path candidate in the
first place (e.g. x:/ or //bleh).  But nowhere else does the server assume
that the results of ap_os_canonical_filename will be a fullpath.  Not even
in Unix.  This is the sort of single platform code that causes nightmare
discrepancies between platforms.

Actually, though, I believe the patch will work on OS2, by virtue that all
the functions (excepting the Alias patch which I am happy to exception for
OS2 to the existing code) are reparsing based on ServerRoot.  If ServerRoot
is assigned early enough in startup (I believe it is), all becomes trivial.

I promise things -will be better- in 2.0 (for anyone, Netware, OS2, Win32,
Mac OS X, OpenVms, and all!) 

But I really want a stable and trustworty 1.3 before I put my own trees to 
bed for good.  Will you, please, give it a quick whack (and tell me if we 
aught to #ifdef out the Alias patch for OS2)?

If you would rather not... I will except via #ifdef OS2 all of the aspects
of this patch.  It chills my spine to have multiple code paths through the
security and parsing, but if that's the way you would rather have it, I will
absolutely respect your authority as maintainer.

View raw message