Hello fellow Symfonizers,
The following was rejected as a bug report on Symfony 1.0.x because it
"could change existing 1.0 application behavior." Which I guess is
true, in a case in which a user is trusting % to be treated literally
in the query string of a URL, although that's not how URLs work in
anybody's mind if they have ever written a non-Symfony web
application.
But if you expect URLs to act like URLs, and especially if you need to
be able to include the & symbol at all as data in a query string
variable passed as part of a Symfony URL, here's the information so
that you can patch Symfony 1.0.x yourself.
(I don't know whether this bug exists in Symfony 1.1, perhaps it has
already been fixed there.)
P.S. Although I spent a lot of time tracking this down and am indeed
frustrated that the problem apparently won't be fixed to save others
the same trouble, I do appreciate the hard work that goes into
building and maintaining Symfony! The grief I went through on this
particular bug doesn't even begin to approach the amount of time I've
saved by using Symfony instead of raw PHP.
* * *
url_for and link_to accept routable Symfony URLs with query string
parameters like so:
module/action?key1=value1&key2=value2
Potentially remapping them according to routing rules and so on,
turning them into better-looking URLs that include the query variables
as path components- which is a very nice feature.
However, if the values passed (or less often, the keys) need to
contain the & sign itself, an escape mechanism is of course needed. As
web developers we all already know what that mechanism is. The
standard mechanism for escaping special characters in URLs is
urlencode() (that is, %XX hex encoding).
Unfortunately, in controller/sfWebController.class.php,
convertUrlStringToParameters unpacks the &-separated Symfony URL
parameter list but never actually urldecodes the keys and values,
accepting them as-is:
foreach ($matches as $match)
{
$params[$match[1][0]] = $match[2][0];
}
Subsequently both the "plain old query" fork and the "routed URL
generator" fork urlencode the keys and values... which are already
urlencoded... resulting in double-urlencoding and ensuing wailing and
crying and gnashing of teeth.
The fact that the parameters do subsequently get urlencoded, even
though they were never urldecoded, clearly makes this an actual bug
and, in my opinion, it really should be fixed.
The correct fix, as I understand it, is:
foreach ($matches as $match)
{
$params[urldecode($match[1][0])] = urldecode($match[2]
[0]);
}
This way the encoding is correctly undone before it is redone.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---
