httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
Date Wed, 27 Feb 2002 22:25:16 GMT
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



Mime
View raw message