This breaks stuff. Consider:
GET http://abcdef/foo%2fbar
and
<Directory proxy:http://abcdef/foo/bar>
...
</Directory>
Of course, this example is already broken by doing this:
GET http://abcdef:80/foo/bar
Or at least I think it is.
Perhaps we should take this time to completely blow away the "special"
proxy r->filename crap. These things are URIs and should never see
the light of day in the filesystem code. They're handled just fine
by <Location>.
Dean
On 8 Jan 1998 marc@hyperreal.org wrote:
> marc 98/01/07 19:56:09
>
> Modified: src/main http_request.c
> Log:
> Move os_canonical_filename call to after the section where
> !os_is_path_absolute names are dealt with to prevent bogus munging
> of things like proxy:
>
> May(?) still cause problems with regex stuff, but fixes proxy caching
> on win32.
>
> Reviewed by: Ben Laurie
>
> Revision Changes Path
> 1.98 +1 -1 apachen/src/main/http_request.c
>
> Index: http_request.c
> ===================================================================
> RCS file: /export/home/cvs/apachen/src/main/http_request.c,v
> retrieving revision 1.97
> retrieving revision 1.98
> diff -u -r1.97 -r1.98
> --- http_request.c 1998/01/07 16:46:12 1.97
> +++ http_request.c 1998/01/08 03:56:08 1.98
> @@ -286,7 +286,6 @@
> return OK;
> }
>
> - r->filename = os_canonical_filename(r->pool, r->filename);
> test_filename = pstrdup(r->pool, r->filename);
>
> /*
> @@ -337,6 +336,7 @@
> return OK;
> }
>
> + r->filename = os_canonical_filename(r->pool, r->filename);
> no2slash(test_filename);
> num_dirs = count_dirs(test_filename);
>
>
>
>
>
|