On Fri, Mar 31, 2023 at 11:23 AM Ruediger Pluem <rpl...@apache.org> wrote: > > On 3/31/23 10:25 AM, Yann Ylavic wrote: > > On Fri, Mar 31, 2023 at 10:15 AM Ruediger Pluem <rpl...@apache.org> wrote: > >> > >> On 3/31/23 9:56 AM, Yann Ylavic wrote: > >>> On Fri, Mar 31, 2023 at 8:28 AM Ruediger Pluem <rpl...@apache.org> wrote: > >>>> > >>>> On 3/31/23 2:11 AM, yla...@apache.org wrote: > >>>>> Author: ylavic > >>>>> Date: Fri Mar 31 00:11:02 2023 > >>>>> New Revision: 1908827 > >>>>> > >>>>> URL: http://svn.apache.org/viewvc?rev=1908827&view=rev > >>>>> Log: > >>>>> mod_proxy: Check for space/ctrls in nocanon path/urls before forwarding. > >>>> > >>>> Can this really happen? Wouldn't this path be rejected during request > >>>> line parsing? > >>> > >>> This is on the suspenders plus belt side (check what we send), but I > >>> suppose that an unfortunate NE[,P] rule could cause it. > >> > >> Don't get me wrong I like better safe than sorry, but can we have nocanon > >> with RewriteRules? > > > > NE,P forces nocanon in mod_rewrite for instance. > > Good catch. I missed this.
I was tempted to not do it for "noencode" (i.e. mapping=encoded) because it is the (most-)fast path for proxying, likely w/o RewriteRules or the users really knowing what they are doing here, but finally went with common code. I could be convinced though :) > > > > >> And if we think that this is a possibility shouldn't we check > >> > >> *ap_scan_vchar_obstext(r->filename) > >> > >> just before returning, to be really sure we missed no edge case? > > > > We could do that, but the path and search parts of the constructed > > r->filename seem to be the only ones we haven't "parsed" in > > canon_handler/ap_proxy_canon_netloc already. > > Ok, fair enough. Do you care to propose for backport such that we get it in > before the tag? Done (STATUS + backport PR #354). Thanks; Yann.
