I am -1 for this patch unless we can fix this problem w/o requiring stating
each and every element when we are walking the file path.
Bill
----- Original Message -----
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 18, 2001 1:33 AM
Subject: A last [extenstive testing required] patch to close 1.3 generation
> I didn't bring this up before 1.3.20, because of it's scope.
>
> We have the essential problems on Win32:
>
> 1. filename case folding doesn't match clib folding [it's oem locale
mapped]
>
> 2. we were folding case, but the ambiguity in the win32 filesystem leads
us
> to stat down the filepath anyways. This became redundant.
>
> 3. we actually stat down the filepath twice, once for true case and once
for
> the 'canonical' lowercase.
>
> I'd like to implement the following straightforward patch:
>
> 1. roll back the case folding altogether, make
r->case_preserved_filename
> point at the same r->filename string, both in true case. We walk the
> filepath only once in our systemcase-canonicalization function. Do
so in
> conjunction with the file_info call, so we don't walk the
non-existant
> path backwards, but the real path, forwards. Suppose that heavy cgi
or
> scripted sites would benefit from tripping that flag, as well, since
they
> wouldn't stat for all the missing /extra segments in the path.
>
> 2. patch the server to assure we are always comparing with case
insensitive
> semantics throughout using strcasecmp or the ignorecase flag to our
> ap_fnmatch function. But change the semantics slightly to use ap_fs_
> case folding functions (mapping to the usual clib on all other
platforms.)
>
> This broad patch would only apply to <File > and <Directory > blocks
and
> filesystem names, and _never_ URI space names.
>
>
> That's it. No optimized rewrite of the directory_walk in 1.3 (it's
written, to
> be committed to the 2.0 branch alone.) Nothing else fancy. Simple, true
case
> that's filesystem API normalized.
>
> Our existing 'overwork' has cost us in performance, but we keep walking on
while
> IIS reveals yet another hole in it's uri->filesystem mapping every month
or few.
> We can recover some of the performance, if we want to go this direction.
>
> I'd reiterate [already wearing my flame-retardant glasses] that I'm of the
opinion
> that the 1.3 chapter of apache is closing (quickly, I hope) but we will
have left
> a more stable product for folks to rely upon while APR and httpd-2.0 go
through
> their growing pains.
>
> If there are objections or hints, I'll take them before I attack. ITMT,
back to
> the 2.0 tree again for me :-)
>
> Bill
>
>
