You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2008/12/14 23:24:59 UTC

DO NOT REPLY [Bug 46358] Treat ';' like '&' in a query string

https://issues.apache.org/bugzilla/show_bug.cgi?id=46358





--- Comment #1 from Bob Ionescu <bo...@googlemail.com>  2008-12-14 14:24:58 PST ---
I think we have to move one step higher...: I'm wondering why we're escaping
the QueryString for a redirect at all. We don't decode the QS if we receive
one, why do we encode the QS if we send a redirect?

Just think about the following situation which creates "bad behavior", too.

RewriteEngine on
RewriteCond %{QUERY_STRING} ^
RewriteRule ^ -
RewriteRule ^/f(.*) /$1 [R,L]

and request GET /foo%25bar?args%25are=bar

You'll get a redirect to /oo%25bar?args%2525are=bar (note the double-encoded %
in the QS; we did not modify the QS with our rule).

If the client requests the given location header, this resolves to r->uri =
/oo%bar and r->args = args%2525are=bar

In that case, the QS is not the same anymore. Using the NE-flag is not an
option, because the URL-path won't be escaped anymore, too, but escaping of '%'
within an URL-path is required. (As a workaround, we could use the internal map
function "escape" for the URL-path in combination with the NE-flag in
server-context, but if you're using the rules in per-dir context without having
access to the server config, you cannot define such a map so I don't consider
this as a solution.) 

Since Apache does not decode the QS while processing the request, why do we
encode it? Note: Using RedirectMatch from mod_alias, only the URL-path but not
the QS is encoded:

RedirectMatch ^/f(.*) http://localhost/$1
request GET /foo%25bar?args%25are=bar
Location header: http://localhost/oo%25bar?args%25are=bar

I'll attach a RewriteLog, the purpose of the first rule is to show the value of
r->args.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org