https://issues.apache.org/bugzilla/show_bug.cgi?id=49642
--- Comment #7 from Eric Covener <[email protected]> --- (In reply to Anders Kaseorg from comment #5) > With this .htaccess file: > > RewriteEngine on > RewriteRule ^page/(.*)$ /cgi-bin/page.cgi/$1 > > a request for page/foo%23bar is rewritten to /cgi-bin/page.cgi/foo (the CGI > script sees PATH_INFO=/foo), and a request for page/foo%3fbar is rewritten > to /cgi-bin/page.cgi/foo?bar (the CGI script sees PATH_INFO=/foo and > QUERY_STRING=bar). I guess the cause is the same here, capturing and substituting the decoded characters and 'B' being unsafe to use in a general purpuse substitution (and requiring per-directory rewrite to allow the re-encoded strings to be decoded again by the core). I haven't looked in detail, but I think in the case of %23 it's the core splitting the URL later as opposed to mod_rewrite splittin the URL shortly after the substitution -- so the solution might be different. >From a workaround perspective, 1) What I would normally suggest here is capturing against %{THE_REQUEST} to deal exclusively with the client-encoded form of the request. 2) for the #, it would seem to be feasible to use [N] and replace #->&23 and not pollute every capturing rule. This doesn't work for ? because the split happens right away. >From a partial fix perspective, Unfortunately I do not really see a full/acceptable or non opt-in fix at this time 1) something like [B=#?] would allow a rule to be fine tuned a little better _after_ finding a problem. I actually like this one as a general tool. 2) an option to split the query string on the right-most question-mark (this by default would break a URL w/ a query passed in the query) 3) some option to remember that the ? was captured at the time we try to split it. Even this breaks captures against %{THE_REQUEST} in a rewritecond. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
