Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020313210854.02386b58@pop3.rowe-clan.net>
Date: Wed, 13 Mar 2002 21:11:01 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [1.3 PATCH/QUESTION] Win32 ap_os_is_filename_valid()
In-Reply-To: <m3elioz3hp.fsf@rdu88-250-166.nc.rr.com>
References: <m3elj6el44.fsf@rdu163-40-092.nc.rr.com>
 <m3elj6el44.fsf@rdu163-40-092.nc.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

+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 <trawick@attglobal.net> 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 | trawick@attglobal.net
>Born in Roswell... married an alien...