>coar 2003/01/23 13:34:14
>
> Modified: include ap_mmn.h http_core.h httpd.h
> server core.c request.c util.c
> Log:
> here we go. add a directive that will keep %2f from being
> decoded into '/', allowing the *_walk to do their magic and
> return 404 if it's in the path, and allowing it in the path-info.
The configuration and context below seems odd to me;
> --- core.c 18 Jan 2003 03:37:54 -0000 1.229
> +++ core.c 23 Jan 2003 21:34:13 -0000 1.230
> @@ -3054,6 +3070,8 @@
> AP_INIT_ITERATE2("AddOutputFilterByType", add_ct_output_filters,
> (void *)APR_OFFSETOF(core_dir_config, ct_output_filters), OR_FILEINFO,
> "output filter name followed by one or more content-types"),
> +AP_INIT_FLAG("AllowEncodedSlashes", set_allow2f, NULL, RSRC_CONF,
> + "Allow URLs containing '/' encoded as '%2F'"),
>
> --- request.c 12 Dec 2002 07:05:54 -0000 1.122
> +++ request.c 23 Jan 2003 21:34:13 -0000 1.123
> @@ -147,13 +147,22 @@
>
> /* Ignore embedded %2F's in path for proxy requests */
> if (!r->proxyreq && r->parsed_uri.path) {
> - access_status = ap_unescape_url(r->parsed_uri.path);
> + core_dir_config *d;
> + d = ap_get_module_config(r->per_dir_config, &core_module);
> + if (d->allow_encoded_slashes) {
> + access_status = ap_unescape_url_keep2f(r->parsed_uri.path);
> + }
> + else {
> + access_status = ap_unescape_url(r->parsed_uri.path);
> + }
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.
Does this make sense?
And what is the impact of this patch on proxies and using mod_rewrite
to proxy certain URIs? It seems folks have %2f's popping up more and
more often in their query args - and we have a number of much more
pressing bugs that the query /foo?answer=yes%2fno would be discarded.
Usually, path_info is under the web developer's control - but the query
string is rarely in our control, but the users/browsers' control.
I'm afraid that the proxied flavor of this would result in ?answer=yes%2fno
which would be re-escaped to the backend server or redirect as something
like ?answer=yes%252fno which would be a real problem.
It would be good to come up with a schema where the unparse/parse would
actually be their reciprocals.
It would be better if unparse/parse would respect the query_args and be
just a little more tolerant of %2f once the path is complete and the query
string begins.
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.
Bill
