On Wed, Mar 13, 2002 at 02:12:18PM -0500, Jeff Trawick wrote: > Jeff Trawick <[EMAIL PROTECTED]> writes: > > > This function is checking for several characters which, at least in > > ASCII, are supposedly not valid characters for filenames. But some of > > these same characters can appear in valid non-ASCII filenames, and the > > logic to check for these characters breaks Apache's ability to serve > > those files. > > > > A user reported the inability to request a file with the Chinese > > character %b5%7c in the name. The %7c byte tripped up the check for > > invalid ASCII characters. > > I think this is an accurate statement regarding the use of non-ASCII > characters in filenames with Apache 1.3 on Win32. Comments? > > -------------------cut here------------------ > Names of file-based resources with Apache 1.3 on Win32 > > Apache 1.3 on Win32 assumes that the names of files served are comprised > solely of characters from the US-ASCII character set. It has no logic to > determine whether or not a possible file name contains invalid non-ASCII > characters. It has no logic to properly match actual non-ASCII file names > with names specified in the Apache configuration file. Because Apache > does not verify that the characters in file names are all ASCII, files > files containing various non-ASCII characters in their names can be > successfully served by Apache. However, this is not recommended for the > following reasons:
No, it doesn't. It treats all names as raw bytes, regardless of charset, but the filtering process of preventing some filesystem-specific magic characters from creating security holes on a server prevents the use of unfiltered 16-bit Unicode or similar wide character sets from being used directly. This is true in general for the Web -- wide character encodings are not allowed to appear in URI under any circumstances. The solution is to use UTF-8 encoding for non-ASCII characters and not allow any access via wide character function calls. ....Roy
