Let's see the patch. Revising my -1 to a -.99 :-)
Bill
> 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
> >
> >
>