+1 ... feel free to profer that 2.0 introduces utf-8 convention to access any filenames and resources in a predictable and safe manner. Since APR does 99% of that magic, backporting that feature to 1.3 is not under consideration.
Bill At 01:12 PM 3/13/2002, you 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: > >1) Because Apache is unable to properly match actual non-ASCII file names > with names in the Apache configuration file, taking into account any > case folding or other transformations handled by the operating system > when looking up files or otherwise matching file names, directives in > the Apache configuration file may or may not be in force, depending > on how the HTTP client specifies the resource. This may be a security > concern, depending on your configuration. > >2) Because Apache assumes that file names are ASCII, some of the checks > it makes when validating file names will flag certain non-ASCII > characters as invalid. For example, Apache on Win32 will flag a file > name containing the ASCII character '|' (0x7C) as invalid. This logic > will flag any file name containing the byte 0x7C as invalid, even if > that byte does not represent '|' in the local character set. There > are other characters checked for as well. Because of these checks, > even if there are no security issues in your configuration, the full > range of local characters cannot be used. > >Because of the lack of proper support for non-ASCII characters in file >names, it is recommended that administrators not attempt to use any >non-ASCII characters in file names. Any other configuration is >unsupported. >------------------cut here---------------- >-- >Jeff Trawick | [EMAIL PROTECTED] >Born in Roswell... married an alien...
