On Wed, 1 Nov 2000 21:17:35 -0600, William A. Rowe, Jr. wrote:
>> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
>> Sent: Wednesday, November 01, 2000 8:39 PM
>>
>> >From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
>> >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
>>
>> 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! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------