DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34602>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34602 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Version|2.0.54 |2.3-HEAD ------- Additional Comments From [EMAIL PROTECTED] 2007-01-25 19:24 ------- (In reply to comment #16) > So [NE] prevents rewrite doing the escaping, and > the RewriteMap causes it to escape the URL it gets, but not the QS it gets. > > I'm not sure it's *right* Yes, I think so, but this is another problem not directly related to the problem described here (rewriting rule-pattern to query string). The current behavior is imho wrong. If we force a redirect, the query string should remain untouched from any escaping intended for uri-paths, because this modifies the query string in an unexpected way. A qs like 'foo%26bar' (location header /foo?foo%2526bar) results in foo%2526bar, which isn't equal to the original query string any more, while a uri like /foo%bar (location header: /foo%25bar) results in /foo%bar. But some specific characters within the query string must be escaped, though (such as spaces). (In reply to comment #5) > 'noescape|NE' (no URI escaping of output) Yes, the NE flag prevents that, but the uri-path may be invalid now since this prevents the URL-path being escaped, too. (In reply to comment #11) > Escape internal redirects for 2.0.55 > > This patch escapes internal redirect requests (just before the message > "internal redirect with..."). This is logical as it seems that the redirection > is fully processed again (unescaped and so on). Yes, this would be logical. The main difference is that this doesn't touch the query string. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
