httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <>
Subject RE: [patch] 1.3.15 ap_os_is_path_absolute
Date Thu, 02 Nov 2000 09:57:54 GMT
On Wed, 1 Nov 2000 21:17:35 -0600, William A. Rowe, Jr. wrote:

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

That's not quite how I see it. To produce a canonical file name you must
map all possible ways of specifying a particular file to a single value.
Considering that the CWD can change, the resulting value MUST be an
absolute path, including the drive letter if on a platform that uses them.

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

No. ap_os_canonical_filename() does this and much more.

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

Not truely. It gets away with it because the CWD is always ServerRoot when
ap_os_canonical_filename() is called and because it doesn't have drive
letters. OS/2 & Win32 have a CWD for each drive letter so if ServerRoot is
C:\httpd the meaning of D:foobar varies with the CWD of D: even if the
current drive is C: and C:'s CWD remains ServerRoot, so D:foobar must
become D:\cwd_of_d\foobar

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

No, that's not how I'd rather do it, I'd prefer to find the correct fix.
Why doesn't ap_os_is_path_absolute() look for backslashes on Win32?

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  |  He's a very naughty boy!" - Life of Brian |

View raw message