[PATCH] Request Parameters get garbled if some of them are empty & link helpers are used.

I have observed this problem too - I'm not sure why your patch changes lib/util/sfSimpleAutoload.class.php though, can you please explain?

This patch is also a little broken... for example

<?php echo url_for('/sip/index?q=test'); ?>
<br />
<?php echo url_for('/sip/index?q='); ?>
<br />

results in

/trunk/web/frontend_dev.php/sip/index/q/test
/trunk/web/frontend_dev.php/sip

before patch, it's

/trunk/web/frontend_dev.php/sip/index/q/test
/trunk/web/frontend_dev.php/sip/index/q

I think accidentally the sfSimpleAutoload file has got into the patch. Will submit the patch without it.

By the way, to your second comment, a parameter without value like "q=" is better to strip off rather than have it, since if we are to leave it in the url, trailing parameters will get wrongly interpreted, which is what this patch fizes.

The only other option is to disallow rewriting 'param=value&' URL strings into '/param/value'

empty params should definatly not be removed IMO, as having an empty param *is* different from having no param at all, and its existence could be used in the application...

IMO, if you don't want an empty param to show, you shouldn't pass it to the URL functions.

The problem here, in my opinion, is that a URL such as

http://.../trunk/web/frontend_dev.php/sip/index/q//page/2

results in:

Request parameters array ( 'module' => 'sip', 'action' => 'index', 'q' => 'page',) 

Which, even if we disagree on whether empty params should show, I'm sure we can agree this is wrong :)

maybe this isn't a symfony problem at all, and simply how pathinfo works...

  'REQUEST_URI' => string '/trunk/web/frontend_dev.php/sip/index/q//page/2' (length=47)
  'SCRIPT_NAME' => string '/trunk/web/frontend_dev.php' (length=27)
  'PATH_INFO' => string '/sip/index/q/page/2' (length=19)
  'PATH_TRANSLATED' => string '/var/www/sip/index/q/page/2' (length=27)
  'PHP_SELF' => string '/trunk/web/frontend_dev.php/sip/index/q//page/2' (length=47)

I believe apache sets the PATH_INFO, which here it's translated the // into a single /

Just so you know, I've removed my interest in this - as I've worked around the issue by using 'query_string' of the link_to helper...

I am now instead doing this:

<?php echo pager_navigation($pager, '/sip/index', array( 'query_params' => array ('q' =>$filterform->getValue('q')))); ?>

and have modifed my pager_navigation helper to do this:

 15   if (isset($options['query_params']))
 16   {
 17     $query_string = http_build_query($options['query_params']);
 18   }

 22     $query_string .= ($query_string ? '&' : '').'page=';

 27       $navigation .= link_to(image_tag('/sf/sf_admin/images/first.png', 'align=absmiddle'), $uri, array('query_string' => $query_string . 1));

This is probably way more information then you needed in this ticket about this problem, but I'm putting it here incase anyone else finds this issue for the same reason I have.

Am remembering now as to why sfSimpleAutoload was added in the patch. The sfSimpleAutoload file patch is meant to suppress a php warning/error message when the glob function call returns null. Had Added this along in the patch, since it is a very trivial change.

New fix for Request garbling ( this fix is for server side), also preserving parameters with empty string as value

The problem is at server side in the url parsing function of routing classes to get request parameters. There is a line which converts multiple consequent slashes into a single slash.

Have fixed the routing classes preserving the parameters having empty values also.

But if the parameter itself is an empty string ( can happen when interpreting url as "key/value/key/value..." ), the parameter and the consequent value are ignored, & processing proceeds to the next parameter. Marking ticket as major since this is a server-side problem.

please see #1824 as well