At 02:16 PM 2/27/2002, you wrote: >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.
You are right - in part - incorrect in part. There are multiple code pages interacting with file names all the time. We are concerned here with the OEM code page, which the console subsystem, and therefore Apache, uses. You are also making assumptions that will eventually trip up and expose security holes [read on]. >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. Apache 1.3 cannot run safely on non-US local code pages unless they are properly supported by the clib and the clib maps to the dos file system. This affects everything, upper/lowercase folding, therefore <Dir > and <File > block restrictions, etc. IIRC, this simply doesn't work correctly in non-us locales. I am working very hard in 2.0 to clean up this mapping by using the underlying file system to report the true names, using utf-8 mappings, and making all external access by Unicode names that aren't volatile between systems. But Apache 1.3 is as safe as we can make it for general use. Please don't be removing restrictions that support that safety, no matter how noble the purpose appears. It was simply never i18n for Win32, and unlike our ongoing faith in and support of 1.3 for Unix, 2.0 will herald a cutoff for recommendations to use the 1.3 codebase on Win32 and some other one-off platforms. Bill
