You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1998/12/03 19:43:39 UTC

Re: [PATCH] Win32 device files

>I wonder if we need test #3 in ap_os_is_filename_valid since 
>ap_os_case_canonical_filename silently removes the trailing '.'?

That isn't desirable, since it opens up a host of cases where
an infinite number of names can map to a resource.  I think it
would be better to find where the "." is being added, since that
sounds like a bogus thing to do in any case.  The only one I can
think of is where "./" is prefixed for relative URI processing,
but that should be removed before any file operation.

....Roy

Re: [PATCH] Win32 device files

Posted by Paul Ausbeck <pa...@alumni.cse.ucsc.edu>.
Joseph Bridgewater wrote:
> 
> I'm just wondering here - is it actually important to support 'Doze95?
> That "os" was never designed to be a server anyway.
> 
Apache already doesn't compile on windows 95 using MSVC 5.0. The problem
is that the distribution uses %PARAM% type arguments in nmake
invokations. On Windows 95, some commands in makefiles are simulated by
nmake itself and those that cannot like nmake itself are invoked
directly, not through the command interpreter. This means that the %%
parameters are just passed directly to the execed program. All nmake
does is change %% to %.

Compile time problems are easier to work around, though, than runtime
problems. To the best of my knowledge, W95 does not exhibit that
particular stat problem.

Paul Ausbeck


RE: [PATCH] Win32 device files

Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 4 Dec 1998, Joseph Bridgewater wrote:

> I'm just wondering here - is it actually important to support 'Doze95?
> That "os" was never designed to be a server anyway.

Some would say that NT wasn't either.

Yes, we "have" to support it.  It doesn't have to be ideal but it has to
work. 



RE: [PATCH] Win32 device files

Posted by Joseph Bridgewater <Jo...@austintx.net>.
I'm just wondering here - is it actually important to support 'Doze95?
That "os" was never designed to be a server anyway.

At 07:51 PM 12/4/98 +0000, Paul Sutton wrote:
>On Thu, 3 Dec 1998, Ken Parzygnat wrote:
>> > I think it
>> > would be better to find where the "." is being added, since that
>> > sounds like a bogus thing to do in any case.  The only one I can
>> > think of is where "./" is prefixed for relative URI processing,
>> > but that should be removed before any file operation.
>> > 
>> 
>> I dug up the following in http_request.c  I don't know that I agree
>> with the comment, but somebody must have seen something at one
>> time.  Does anyone remember?
>> 
>> #ifdef WIN32
>>     /* If the path is x:/, then convert it to x:/., coz that's what stat
>>      * needs to work properly
>>      */
>
>Umm, who knows? I've just tried it on NT 4 SP4 and stat works with or
>without a trailing . (or in fact, any number of trailing dots). (Small
>test program available on request, if anyone else wants to try on
>different systems).
>
>Part of the problem with supporting Windows is that there are lots of
>incompatibilities between different versions (95/NT), releases, service
>pack updates, MSIE versions, and all the other little packages and
>products which "upgrade" your "system" libraries (if Windows has such as
>concept). So this was probably true on some configuration somewhere, and
>it would be nice to find a list of all the differences between different
>versions of the standard DLL's somewhere (say on MS's site!) but I don't
>think there is one. 
>
>Paul

RE: [PATCH] Win32 device files

Posted by Joseph Bridgewater <Jo...@austintx.net>.
At 11:30 AM 12/5/98 -0500, Ken Parzygnat wrote:
<snip>
> breaks with ap_os_is_filename_valid because it is getting
>passed the name "//.htaccess".  I traced it back to the 
>directory_walk routine.  We're not handling UNC names there
>correctly.  The name //machine/share/ is seen as 4 directories.
>So we first look for /.htaccess, then //.htaccess
>Seems to me that we need to initally jump past the machine
>and share name before we start doing the walking.

I'm sorry to offer this so incompletely, but I believe that essentially in
*every* case, "\\machine\share\" needs to be treated atomically *exactly*
as thought it were "x:".  Essentially you need to detect a UNC construction
at the earliest possible point (perhaps per sub, or perhaps one detection
can care for lower level subs) and not try to ever break it up or delve
deeper into it (same as you wouldn't try to break up x and delve into it).

Re: [PATCH] Win32 device files

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ken Parzygnat wrote:
> 
> Grrrr... iStart declared as wrong type,
> here's a refresh.

Do we have any other Win32 hackers who can vet this?
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

RE: [PATCH] Win32 device files

Posted by Ken Parzygnat <kp...@raleigh.ibm.com>.
Grrrr... iStart declared as wrong type, 
here's a refresh.



--- http_request.c.first	Thu Dec 03 14:29:14 1998
+++ http_request.c	Mon Dec 07 21:01:14 1998
@@ -179,7 +179,6 @@
     char *last_cp = NULL;
     int rv;
 #ifdef WIN32
-    char buf[5];
     BOOL bStripSlash=TRUE;
 #endif

@@ -189,16 +188,12 @@
     }

 #ifdef WIN32
-    /* If the path is x:/, then convert it to x:/., coz that's what stat
-     * needs to work properly
+    /* If the directory is x:\, then we don't want to strip
+     * the trailing slash since x: is not a valid directory.
      */
-    if (strlen(path) == 3 && path[1] == ':') {
-	strcpy(buf,path);
-	buf[3]='.';
-	buf[4]='\0';
-	path=buf;
-	end=buf+4;
-    }
+    if (strlen(path) == 3 && path[1] == ':' && path[2] == '/')
+        bStripSlash = FALSE;
+

     /* If UNC name == //machine/share/, do not
      * advance over the trailing slash.  Any other
@@ -333,7 +328,7 @@
     char *test_filename;
     char *test_dirname;
     int res;
-    unsigned i, num_dirs;
+    unsigned i, num_dirs, iStart;
     int j, test_filename_len;

     /*
@@ -441,9 +436,18 @@
      */
     test_dirname = ap_palloc(r->pool, test_filename_len + 2);

+    iStart = 1;
+#ifdef WIN32
+    /* If the name is a UNC name, then do not walk through the
+     * machine and share name (e.g. \\machine\share\)
+     */
+    if (num_dirs > 3 && test_filename[0] == '/' && test_filename[1] == '/')
+        iStart = 4;
+#endif
+
     /* j keeps track of which section we're on, see core_reorder_directories */
     j = 0;
-    for (i = 1; i <= num_dirs; ++i) {
+    for (i = iStart; i <= num_dirs; ++i) {
         int overrides_here;
         core_dir_config *core_dir = (core_dir_config *)
             ap_get_module_config(per_dir_defaults, &core_module);

- - - - - - - - - - - - - - - - - -
Ken Parzygnat
email: kparz@raleigh.ibm.com 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --------------------------------------------------------------------------------
> > Users of the Apache webserver are hereby granted a non-exclusive, irrevocable,
> > world-wide, royalty-free, non-transferable license to use, execute, prepare
> > derivative works of, and distribute (internally and externally, and including
> > derivative works) the code accompanying this license as part of, and
> > integrated into the Apache webserver.  This code is provided "AS IS" WITHOUT
> > WARRANTY OF ANY KIND EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
> > THE IMPLIED WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > AND ANY WARRANTY OF NON-INFRINGEMENT.  THE ENTIRE RISK ARISING OUT OF THE USE
> > OR PERFORMANCE OF THIS CODE REMAINS WITH USERS OF THE APACHE WEBSERVER.  The
> > owner of this code represents and warrants that it is legally entitled to
> > grant the above license.
> > 
> 

RE: [PATCH] Win32 device files

Posted by Ken Parzygnat <kp...@raleigh.ibm.com>.
Ok, how about this.  I've attempted to fix
directory_walk by detecting if we have a UNC name,
and if so, I start the walk after the share.

I've appended the fix to the end of the last patch
I submitted, so this one patch should fix both problems.

You see any problems? 

--- http_request.c.first	Thu Dec 03 14:29:14 1998
+++ http_request.c	Mon Dec 07 18:57:57 1998
@@ -179,7 +179,6 @@
     char *last_cp = NULL;
     int rv;
 #ifdef WIN32
-    char buf[5];
     BOOL bStripSlash=TRUE;
 #endif

@@ -189,16 +188,12 @@
     }

 #ifdef WIN32
-    /* If the path is x:/, then convert it to x:/., coz that's what stat
-     * needs to work properly
+    /* If the directory is x:\, then we don't want to strip
+     * the trailing slash since x: is not a valid directory.
      */
-    if (strlen(path) == 3 && path[1] == ':') {
-	strcpy(buf,path);
-	buf[3]='.';
-	buf[4]='\0';
-	path=buf;
-	end=buf+4;
-    }
+    if (strlen(path) == 3 && path[1] == ':' && path[2] == '/')
+        bStripSlash = FALSE;
+

     /* If UNC name == //machine/share/, do not
      * advance over the trailing slash.  Any other
@@ -334,7 +329,7 @@
     char *test_dirname;
     int res;
     unsigned i, num_dirs;
-    int j, test_filename_len;
+    int j, test_filename_len, iStart;

     /*
      * Are we dealing with a file? If not, we can (hopefuly) safely assume we
@@ -441,9 +436,18 @@
      */
     test_dirname = ap_palloc(r->pool, test_filename_len + 2);

+    iStart = 1;
+#ifdef WIN32
+    /* If the name is a UNC name, then do not walk through the
+     * machine and share name (e.g. \\machine\share\)
+     */
+    if (num_dirs > 3 && test_filename[0] == '/' && test_filename[1] == '/')
+        iStart = 4;
+#endif
+
     /* j keeps track of which section we're on, see core_reorder_directories */
     j = 0;
-    for (i = 1; i <= num_dirs; ++i) {
+    for (i = iStart; i <= num_dirs; ++i) {
         int overrides_here;
         core_dir_config *core_dir = (core_dir_config *)
             ap_get_module_config(per_dir_defaults, &core_module);

- - - - - - - - - - - - - - - - - -
Ken Parzygnat
email: kparz@raleigh.ibm.com 

 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------------------
> Users of the Apache webserver are hereby granted a non-exclusive, irrevocable,
> world-wide, royalty-free, non-transferable license to use, execute, prepare
> derivative works of, and distribute (internally and externally, and including
> derivative works) the code accompanying this license as part of, and
> integrated into the Apache webserver.  This code is provided "AS IS" WITHOUT
> WARRANTY OF ANY KIND EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
> THE IMPLIED WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> AND ANY WARRANTY OF NON-INFRINGEMENT.  THE ENTIRE RISK ARISING OUT OF THE USE
> OR PERFORMANCE OF THIS CODE REMAINS WITH USERS OF THE APACHE WEBSERVER.  The
> owner of this code represents and warrants that it is legally entitled to
> grant the above license.
> 

RE: [PATCH] Win32 device files

Posted by Ken Parzygnat <kp...@raleigh.ibm.com>.
[...]
> > 
> > #ifdef WIN32
> >     /* If the path is x:/, then convert it to x:/., coz that's what stat
> >      * needs to work properly
> >      */
> 
> Umm, who knows? I've just tried it on NT 4 SP4 and stat works with or
> without a trailing . (or in fact, any number of trailing dots). (Small
> test program available on request, if anyone else wants to try on
> different systems).
> 
> Part of the problem with supporting Windows is that there are lots of
> incompatibilities between different versions (95/NT), releases, service
> pack updates, MSIE versions, and all the other little packages and
> products which "upgrade" your "system" libraries (if Windows has such as
> concept). So this was probably true on some configuration somewhere, and
> it would be nice to find a list of all the differences between different
> versions of the standard DLL's somewhere (say on MS's site!) but I don't
> think there is one. 
> 

I've solved one part of the problem.  The adding of the '.' to names
like x:/ appears to have been necessary because of the code that 
follows.  It attempts to remove the trailing '/' from the name.  This is
usually OK, except when you have x:/ because x: is not a valid directory.
I wrote some code to fix this for UNC names, because you have the 
same problem with //machine/share and //machine/share/  
I was able to make the same adjustment for x:/
I've placed the patch below.

The second problem I'd found may be a little more sticky.  The 
problem was when I specify a UNC alias
Alias /shareme/ //machine/share/

This breaks with ap_os_is_filename_valid because it is getting
passed the name "//.htaccess".  I traced it back to the 
directory_walk routine.  We're not handling UNC names there
correctly.  The name //machine/share/ is seen as 4 directories.
So we first look for /.htaccess, then //.htaccess
Seems to me that we need to initally jump past the machine
and share name before we start doing the walking.

Maybe someone who is more intimate with
directory_walk could spot an easy fix.


--- http_request.c.first	Sat Dec 05 13:59:24 1998
+++ http_request.c	Sat Dec 05 14:32:36 1998
@@ -179,7 +179,6 @@
     char *last_cp = NULL;
     int rv;
 #ifdef WIN32
-    char buf[5];
     BOOL bStripSlash=TRUE;
 #endif

@@ -189,16 +188,12 @@
     }

 #ifdef WIN32
-    /* If the path is x:/, then convert it to x:/., coz that's what stat
-     * needs to work properly
+    /* If the directory is x:\, then we don't want to strip
+     * the trailing slash since x: is not a valid directory.
      */
-    if (strlen(path) == 3 && path[1] == ':') {
-	strcpy(buf,path);
-	buf[3]='.';
-	buf[4]='\0';
-	path=buf;
-	end=buf+4;
-    }
+    if (strlen(path) == 3 && path[1] == ':' && path[2] == '/')
+        bStripSlash = FALSE;
+

     /* If UNC name == //machine/share/, do not
      * advance over the trailing slash.  Any other



- - - - - - - - - - - - - - - - - -
Ken Parzygnat
email: kparz@raleigh.ibm.com 











--------------------------------------------------------------------------------
Users of the Apache webserver are hereby granted a non-exclusive, irrevocable,
world-wide, royalty-free, non-transferable license to use, execute, prepare
derivative works of, and distribute (internally and externally, and including
derivative works) the code accompanying this license as part of, and
integrated into the Apache webserver.  This code is provided "AS IS" WITHOUT
WARRANTY OF ANY KIND EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE IMPLIED WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
AND ANY WARRANTY OF NON-INFRINGEMENT.  THE ENTIRE RISK ARISING OUT OF THE USE
OR PERFORMANCE OF THIS CODE REMAINS WITH USERS OF THE APACHE WEBSERVER.  The
owner of this code represents and warrants that it is legally entitled to
grant the above license.

RE: [PATCH] Win32 device files

Posted by Paul Sutton <pa...@c2.net>.
On Thu, 3 Dec 1998, Ken Parzygnat wrote:
> > I think it
> > would be better to find where the "." is being added, since that
> > sounds like a bogus thing to do in any case.  The only one I can
> > think of is where "./" is prefixed for relative URI processing,
> > but that should be removed before any file operation.
> > 
> 
> I dug up the following in http_request.c  I don't know that I agree
> with the comment, but somebody must have seen something at one
> time.  Does anyone remember?
> 
> #ifdef WIN32
>     /* If the path is x:/, then convert it to x:/., coz that's what stat
>      * needs to work properly
>      */

Umm, who knows? I've just tried it on NT 4 SP4 and stat works with or
without a trailing . (or in fact, any number of trailing dots). (Small
test program available on request, if anyone else wants to try on
different systems).

Part of the problem with supporting Windows is that there are lots of
incompatibilities between different versions (95/NT), releases, service
pack updates, MSIE versions, and all the other little packages and
products which "upgrade" your "system" libraries (if Windows has such as
concept). So this was probably true on some configuration somewhere, and
it would be nice to find a list of all the differences between different
versions of the standard DLL's somewhere (say on MS's site!) but I don't
think there is one. 

Paul


RE: [PATCH] Win32 device files

Posted by Ken Parzygnat <kp...@raleigh.ibm.com>.
> I think it
> would be better to find where the "." is being added, since that
> sounds like a bogus thing to do in any case.  The only one I can
> think of is where "./" is prefixed for relative URI processing,
> but that should be removed before any file operation.
> 

I dug up the following in http_request.c  I don't know that I agree
with the comment, but somebody must have seen something at one
time.  Does anyone remember?

#ifdef WIN32
    /* If the path is x:/, then convert it to x:/., coz that's what stat
     * needs to work properly
     */
    if (strlen(path) == 3 && path[1] == ':') {
	strcpy(buf,path);
	buf[3]='.';
	buf[4]='\0';
	path=buf;
	end=buf+4;
    }

- - - - - - - - - - - - - - - - - -
Ken Parzygnat
email: kparz@raleigh.ibm.com