William A. Rowe, Jr. wrote:
>
> The configuration and context below seems odd to me;
:
> You haven't resolved any <Directory>, <Files>, <Locations> etc in the
> code fragment above... it's too early in the request processing cycle.
> It seems this should not be a dir_conf flag, but actually a server_conf flag
> since your patch only resolves the directive relative to a given server.
that's right, i didn't. as explained earlier, this is currently
RSRC_CONF, which means it *can't* appear in any of those containers,
so that point is moot. that makes it essentially server-scope --
but by treating it as per-dir now, we don't need to shift from
per-server to per-dir when we have a more finely grained solution.
> And what is the impact of this patch on proxies and using mod_rewrite
> to proxy certain URIs?
i will investigate. i'm tempted to consider this a piece
of rope, however, and as long as it doesn't open any security
exposures, caveat emptor.
> It would be best if we unparsed and tracked the offsets in the source and
> unescaped query strings of individual components (scheme, user, host,
> path, path_info and query). We could do something as simple as counting
> the number of slashes in the source and target paths, and failing only when
> those two components mismatch.
this has been mentioned several times as a 'gee, it would be
nice.' unfortunately, it is also a major hassle due to all the
rewriting potential, et cetera. it's definitely for later.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
