Currenty symfony can create urls containing urlencoded slash (%2F),
which does not work for apache*, it throws right away 404 without even
looking at rewrite rules. This can be seen for example in sfSimpleCMS
plugin, where publich/unpublish/delete actions don't work for slugs
containing /
I don't think urlencoding of slash is necessery:
- symfony will receive decoded slash in either case (in case it's
encoded, AllowEncodedSlashes must be On)
- for parameters that might contain slash, "requirements: { paramname:
'.*'}" is required in routing configuration, and this will "eat" the
rest of the url, be it encoded or not.
I propose this change in controller/sfRouting.class.php - just before
return from generate() function, remove encoding of slash:
$real_url = str_ireplace('%2F', '/', $real_url);
Any comments on this?
-- Marek
* It's possible to set AllowEncodedSlashes to On, but this setting is
only per server and vhost, and most hosts don't allow changing vhosts
sections.
> Currenty symfony can create urls containing urlencoded slash (%2F), > which does not work for apache*, it throws right away 404 without even > looking at rewrite rules. This can be seen for example in sfSimpleCMS > plugin, where publich/unpublish/delete actions don't work for slugs > containing /
See also: [symfony-users] escaping escaping in URLs
I think it's completely unnecessary to escape / characters in URLs. It
is only necessary to escape those characters that are not permissible
in URLs and those characters that have syntactic meaning (especially &
and =).
Rick
On Mar 3, 12:56 pm, "Ian P. Christian" <poo...@pookey.co.uk> wrote:
> > Currenty symfony can create urls containing urlencoded slash (%2F),
> > which does not work for apache*, it throws right away 404 without even
> > looking at rewrite rules. This can be seen for example in sfSimpleCMS
> > plugin, where publich/unpublish/delete actions don't work for slugs
> > containing /
> I think it's completely unnecessary to escape / characters in URLs. It > is only necessary to escape those characters that are not permissible > in URLs and those characters that have syntactic meaning (especially & > and =).
If you're not going to fully escape URL parameters, how do you represent a slug (or some other value) in a URL with a / in it?
> On Mar 3, 12:56 pm, "Ian P. Christian" <poo...@pookey.co.uk> wrote: >> Marek wrote: >>> Hi devs,
>>> Currenty symfony can create urls containing urlencoded slash (%2F), >>> which does not work for apache*, it throws right away 404 without >>> even >>> looking at rewrite rules. This can be seen for example in >>> sfSimpleCMS >>> plugin, where publich/unpublish/delete actions don't work for slugs >>> containing /
On 5. Mar., 15:28 h., Jacob Coby <jc...@portallabs.com> wrote:
> On Mar 5, 2008, at 6:44 AM, RickB wrote:
> > I think it's completely unnecessary to escape / characters in URLs. It
> > is only necessary to escape those characters that are not permissible
> > in URLs and those characters that have syntactic meaning (especially &
> > and =).
> If you're not going to fully escape URL parameters, how do you
> represent a slug (or some other value) in a URL with a / in it?
I'm talking about URL without query string, that's everything that
comes before the first "?".
Escaping / there makes apache serve 404 page for any request.
On Mar 5, 2:28 pm, Jacob Coby <jc...@portallabs.com> wrote:
> If you're not going to fully escape URL parameters, how do you
> represent a slug (or some other value) in a URL with a / in it?
Ah! I understand your problem now - you're asking about a RESTful URL
with the request parameters converted to look like a long path.
E.g. /index.php?arg=my/slug would need to be converted to /arg/my/slug
but this raises a problem due to the / character being used to delimit
arguments and values.
The original case (/index.php?arg=my/slug) does not have a problem
with / characters in parameters - it's fully legit in URLs to do
this. The problem only arises because of converting the request
parameters to look like a long URL, in which the / character takes on
a new meaning as the element delimiter (instead of ? and &).
I have some suggestions for what they're worth: either
1. escape the / as %2F
2. convert the / to \ for this purpose only (which would be a
reasonable thing to do - backslashes don't have any formal meaning in
URLs - however this is likely not to work in IE, which treats \ and /
as equivalent in spite of the standard definition of a URL).
3. don't use long URLs but go back to parameter lists (eg. /index.php?
arg=my/slug) when this is a problem.
The problem is a common one. Symfony needs to URL-encode the parameters, so that blank spaces in parameters do not make invalid URLs. For instance, it is possible to call:
url_for('foo/bar/msg=hello, world!')
And you do need urlencoding for this to work. If you look at the way the routing works, you will also see that it would complexify the code quite a lot to allow users to define a per-parameter encoding option.
As for the / being turned into a %2F because of that, a common workaround is to dedicate a special helper to build the links containing a path. Look at what was done in sfSimpleCMSPlugin:
> On Mar 5, 2:28 pm, Jacob Coby <jc...@portallabs.com> wrote:
> > If you're not going to fully escape URL parameters, how do you > > represent a slug (or some other value) in a URL with a / in it?
> Ah! I understand your problem now - you're asking about a RESTful URL > with the request parameters converted to look like a long path.
> E.g. /index.php?arg=my/slug would need to be converted to /arg/my/slug > but this raises a problem due to the / character being used to delimit > arguments and values.
> The original case (/index.php?arg=my/slug) does not have a problem > with / characters in parameters - it's fully legit in URLs to do > this. The problem only arises because of converting the request > parameters to look like a long URL, in which the / character takes on > a new meaning as the element delimiter (instead of ? and &).
> I have some suggestions for what they're worth: either
> 1. escape the / as %2F > 2. convert the / to \ for this purpose only (which would be a > reasonable thing to do - backslashes don't have any formal meaning in > URLs - however this is likely not to work in IE, which treats \ and / > as equivalent in spite of the standard definition of a URL). > 3. don't use long URLs but go back to parameter lists (eg. /index.php? > arg=my/slug) when this is a problem.
hay man you can do this this wrong return str_replace('%2F', '/',
link_to($text, $uri, $options)); the right code is link_to('text','/
company/index?company_id='.$company->getId().'&tab=news'
khaled wrote: > hay man you can do this this wrong return str_replace('%2F', '/', > link_to($text, $uri, $options)); the right code is link_to('text','/ > company/index?company_id='.$company->getId().'&tab=news'
Do you realise who your post was addressing? ;) That was Francois, of... symfony fame :P
Anyway, you're wrong, please read the whole thread before posting next time. To help you understand, the problem is when one of your params contains a '/' itself