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!"