httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c
Date Mon, 28 Jan 2002 18:47:54 GMT
From: <gregames@apache.org>
Sent: Monday, January 28, 2002 12:43 PM


> gregames    02/01/28 10:43:19
> 
>   Modified:    modules/mappers mod_negotiation.c
>   Log:
>   handle_multi: pass along the original path info and query string if
>   we redirect due to negotiation
>   
>   pointed out by: Bill Rowe
>   
>   also, clarify what some code in handle_map_file is doing
>   
>   Revision  Changes    Path
>   1.92      +8 -6      httpd-2.0/modules/mappers/mod_negotiation.c
>   @@ -2828,13 +2828,11 @@
>            return ap_pass_brigade(r->output_filters, bb);
>        }
>    
>   -    /* XXX This looks entirely bogus.  Why can't negotiated content
>   -     *     have additional path_info?  Just because I choose a given
>   -     *     script based on content type doesn't mean I don't want it
>   -     *     to run the same set of actions (think three languages of
>   -     *     viewcvs.cgi.xx, all serving the same repository.)
>   -     */
>        if (r->path_info && *r->path_info) {
>   +        /* remove any path_info from the end of the uri before trying
>   +         * to change the filename.  r->path_info from the original
>   +         * request is passed along on the redirect.
>   +         */
>            r->uri[ap_find_path_info(r->uri, r->path_info)] = '\0';
>        }
>        udir = ap_make_dirstr_parent(r->pool, r->uri);
>   @@ -2894,6 +2892,10 @@
>            }
>        }
>    
>   +    /* preserve path info and query string from the original request */
>   +    sub_req->path_info = r->path_info;
>   +    sub_req->args = r->args;
>   +    
>        /* now do a "fast redirect" ... promotes the sub_req into the main req */
>        ap_internal_fast_redirect(sub_req, r);

I need to veto this patch.

YOU CANNOT attempt to create one subrequest, then run another subrequest.

It's entirely invalid... The request didn't have the opportunity to create the
proper subrequest for the 'real' args.  Especially with ap_internal_fast_redirect
this is a serious security hole.

Please Revert, then explain what problem you were solving.

Bill


Mime
View raw message