Development

#3788 (convertUrlStringToParameters breaks urlencoded parameters)

You must first sign up to be able to contribute.

Ticket #3788 (reopened defect)

Opened 6 months ago

Last modified 5 months ago

convertUrlStringToParameters breaks urlencoded parameters

Reported by: boutell Assigned to: fabien
Priority: major Milestone: 1.0.17
Component: controller Version:
Keywords: urlencode, parameters, routing Cc:
Qualification: Unreviewed

Description

url_for accepts Symfony URLs with parameters like so:

module/action?key1=value1&key2=value2

Potentially remapping them according to routing rules and so on.

If the values passed need to contain the & sign, an escape mechanism is therefore needed. The standard mechanism for URLs like this everywhere else, of course, is urlencode().

However convertUrlStringToParameters unpacks the &-separated parameter list but never actually decodes 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 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.

Change History

06/24/08 11:36:46 changed by hartym

  • version deleted.
  • milestone deleted.

Sorry, but this can change 1.0 behaviour for existing project.

06/28/08 09:21:42 changed by fabien

  • status changed from new to closed.
  • resolution set to fixed.

(In [9956]) fixed convertUrlStringToParameters breaks urlencoded parameter (closes #3788)

06/28/08 09:23:15 changed by fabien

(In [9957]) fixed convertUrlStringToParameters breaks urlencoded parameter (closes #3788)

06/28/08 09:23:37 changed by fabien

  • milestone set to 1.0.17.

06/30/08 15:49:47 changed by selimachour

  • status changed from closed to reopened.
  • resolution deleted.

Hi Fabien

I used to have an

urldecode(url_for("@member_viewList?id='+ id +'"));

used to generate (in a javascript)

load('/path_to_root/web/member/viewList/'+ id +);

After [9957], the url generated is

load('/path_to_root/web/member/viewList/' id );

hense not working anymore becos of the missing + signe.

This forces me to encode the + signe manually in order to make it work.

load('/path_to_root/web/member/viewList/'%2B id %2B);

This works for me but thought I'd let you know

07/11/08 14:51:34 changed by gert

Same here... this clearly breaks BC I had trouble with several projects after upgrading to 1.0.17

07/11/08 16:28:34 changed by boutell

I appreciate that this is frustrating for folks who had already worked around the existing behavior, but IMHO the use of a standard convention like:

?key=val&key2=val2...

Strongly implies that the keys and parameters should actually be encoded according to that convention. If it looks like a GET-method query string it should behave like one.

Equally important, while the fix prevents the use of + as a literal, without the fix it isn't possible to encode & at all, as a literal or otherwise. This was forcing us to give up on routable URLs and use the query_string option.

If we absolutely must make allowance for reverting to the old behavior, how about a settings.yml flag to turn off the urldecode calls? Of couse we wouldn't want that to carry forward to 1.1, where developers have a stronger expectation that some changes to existing code may be necessary... ugly workarounds should have sunset dates.