On Mon, Nov 28, 2011 at 9:38 AM, Joe Orton <[email protected]> wrote: > On Thu, Nov 24, 2011 at 11:37:34PM +0100, Rainer Jung wrote: >> Don't know whether that could happen here, but could "OPTIONS *" be >> a problem? > > Hmmm, another good question. > > What should mod_rewrite or mod_proxy's translate_name hook do for a > request-URI of "*"? 2616 says: > > The asterisk "*" means that the request does not apply to a > particular resource, but to the server itself > > ... so I would say they should return DECLINED for "*"? It makes no > sense to apply rewrite rules against "*", nor can it be proxied. > > Index: modules/mappers/mod_rewrite.c > =================================================================== > --- modules/mappers/mod_rewrite.c (revision 1203669) > +++ modules/mappers/mod_rewrite.c (working copy) > @@ -4266,6 +4266,18 @@ > return DECLINED; > } > > + if (strcmp(r->unparsed_uri, "*") == 0) { > + /* Don't apply rewrite rules to "*". */ > + return DECLINED; > + } > + > + /* Check that the URI is valid. */ > + if (!r->uri || r->uri[0] != '/') { > + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, > + "Invalid URI in request %s", r->the_request); > + return HTTP_BAD_REQUEST; > + } > + > /* > * add the SCRIPT_URL variable to the env. this is a bit complicated > * due to the fact that apache uses subrequests and internal redirects > Index: modules/proxy/mod_proxy.c > =================================================================== > --- modules/proxy/mod_proxy.c (revision 1203669) > +++ modules/proxy/mod_proxy.c (working copy) > @@ -566,6 +566,18 @@ > return OK; > } > > + if (strcmp(r->unparsed_uri, "*") == 0) { > + /* "*" cannot be proxied. */ > + return DECLINED; > + } > + > + /* Check that the URI is valid. */ > + if (!r->uri || r->uri[0] != '/') { > + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, > + "Invalid URI in request %s", r->the_request); > + return HTTP_BAD_REQUEST; > + } > + > /* XXX: since r->uri has been manipulated already we're not really > * compliant with RFC1945 at this point. But this probably isn't > * an issue because this is a hybrid proxy/origin server.
The new code and the core translate name hook agree on something critical: if it isn't "*" and it isn't a fully qualified path, return 400. For proxy and rewrite to return 400 without knowing if these were proxied or rewritten requests implies that it is never valid (as returning 400 from those hooks will bypass other hooks that might be able to handle that). One of the following should be true: a) (if always invalid) core should check the condition before running translate name b) (if not always invalid) proxy and rewrite should decline (like alias) instead of returning 400, in case there is still another hook that runs before core and needs to handle it Make sense?
