You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/11/01 22:00:13 UTC
[patch] 1.3.15 ap_os_is_path_absolute
From: "William A. Rowe, Jr." <wr...@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
check out the behavior on OS2?
Index: main/http_config.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_config.c,v
retrieving revision 1.154
diff -u -r1.154 http_config.c
--- main/http_config.c 2000/10/03 16:39:40 1.154
+++ main/http_config.c 2000/11/01 20:28:01
@@ -1090,6 +1090,7 @@
so the server can be moved or mirrored with less pain. */
char *p;
int offset = (int) (long) cmd->info;
+ arg = ap_os_canonical_filename(cmd->pool, arg);
if (ap_os_is_path_absolute(arg))
p = arg;
else
@@ -1108,6 +1109,7 @@
API_EXPORT(char *) ap_server_root_relative(pool *p, char *file)
{
+ file = ap_os_canonical_filename(p, file);
if(ap_os_is_path_absolute(file))
return file;
return ap_make_full_path(p, ap_server_root, file);
[patch] 1.3.15 ap_os_is_path_absolute
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Here is the final patch to fix the naming issues for both
aliases (except for regex aliases!) and general config
directive paths.
I've bashed on it and will commit tommorow bright and early
unless anyone screams (yes - it's rtc... so review :-)
Similar patches to appear in 2.0 will actually rely on
the canonical functions which are still WIP.
With these two patches I'm about ready to sign off on the
1.3.15 bugfix release, but I have to reload the Win95 OS
on my desktop to debug the cgi execution errors on Win95,
since Win98 apparently cooperates with the existing code.
Index: main/http_config.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_config.c,v
retrieving revision 1.154
diff -u -r1.154 http_config.c
--- main/http_config.c 2000/10/03 16:39:40 1.154
+++ main/http_config.c 2000/11/01 22:10:50
@@ -1090,6 +1090,7 @@
so the server can be moved or mirrored with less pain. */
char *p;
int offset = (int) (long) cmd->info;
+ arg = ap_os_canonical_filename(cmd->pool, arg);
if (ap_os_is_path_absolute(arg))
p = arg;
else
@@ -1108,6 +1109,7 @@
API_EXPORT(char *) ap_server_root_relative(pool *p, char *file)
{
+ file = ap_os_canonical_filename(p, file);
if(ap_os_is_path_absolute(file))
return file;
return ap_make_full_path(p, ap_server_root, file);
Index: modules/standard/mod_alias.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_alias.c,v
retrieving revision 1.41
diff -u -r1.41 mod_alias.c
--- modules/standard/mod_alias.c 1999/05/21 12:16:26 1.41
+++ modules/standard/mod_alias.c 2000/11/01 22:10:56
@@ -137,10 +137,12 @@
new->regexp = ap_pregcomp(cmd->pool, f, REG_EXTENDED);
if (new->regexp == NULL)
return "Regular expression could not be compiled.";
+ new->real = r;
}
+ else
+ new->real = ap_os_canonical_filename(cmd->pool, r);
new->fake = f;
- new->real = r;
new->handler = cmd->info;
return NULL;
@@ -233,7 +235,7 @@
"a fakename and a realname"},
{"Redirect", add_redirect, (void *) HTTP_MOVED_TEMPORARILY,
OR_FILEINFO, TAKE23,
- "an optional status, then document to be redirected and destination URL"},
+ "an optional status, then document to be redirected and destination URL"},
{"AliasMatch", add_alias_regex, NULL, RSRC_CONF, TAKE2,
"a regular expression and a filename"},
{"ScriptAliasMatch", add_alias_regex, "cgi-script", RSRC_CONF, TAKE2,
@@ -339,7 +341,6 @@
return found;
}
-
}
return NULL;
RE: [patch] 1.3.15 ap_os_is_path_absolute
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Wednesday, November 01, 2000 8:39 PM
>
> >From: "William A. Rowe, Jr." <wr...@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
> >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.
Re: [patch] 1.3.15 ap_os_is_path_absolute
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Wed, 1 Nov 2000 15:00:13 -0600, William A. Rowe, Jr. wrote:
>From: "William A. Rowe, Jr." <wr...@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
>check out the behavior on OS2?
Err, no. I'd much rather you used a more appropriate function, say:
void ap_fix_slashes(char *szFile)
{
/* Switch backslashes to forward */
char *pos;
for (pos=szFile; *pos; pos++)
if (*pos == '\\')
*pos = '/';
}
Why are you so keen to use ap_os_canonical_filename() when you're not
actually after a canonical file name?
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.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------