Issue Type: Bug Created: 2008-07-28T10:28:55.000+0000 Last Updated: 2011-10-17T19:33:23.000+0000 Status: Open Fix version(s): - Next Major Release ()
Reporter: Ben Scholzen (dasprid) Assignee: Ben Scholzen (dasprid) Tags: - Zend_View
Related issues: Attachments:
The URL view helper currently does automatically escape html special chars, so it has to be done manually yet. Since it is only intended for the view, it actually should.
Posted by Jon Whitcraft (sidhighwind) on 2008-10-23T18:38:43.000+0000
Can you provide a use case to for this? To me since it just uses the router to assemble the url you should have to escape the data before you pass it in. But if you can make a good case for this it can be considered for a change.
Posted by Ben Scholzen (dasprid) on 2008-10-24T00:11:12.000+0000
Yeah sure (and hi Jon, btw, hope you remember me ;)).
When creating a URL in a view, which creates an ampersand, double-quotes or other characters (which are valid for URLs), the generated source code isn't valid anymore. Since this is a view helper, it should escape it's output with the escape() view helper.
Posted by Jon Whitcraft (sidhighwind) on 2008-10-24T07:42:42.000+0000
Yes i do remember you. And What view helper are you using? I'm using The Rewirte Router (urls are formated like /help/1/foo/bar) so i don't get the ? and & on my urls. I think this may be a possibility to change but it has to be specific to a router...
Posted by Jon Whitcraft (sidhighwind) on 2008-10-24T07:53:37.000+0000
Can you also produce a test case for this issue?
Posted by Ben Scholzen (dasprid) on 2008-10-24T08:28:59.000+0000
I could even do the changes myself, I just didn't to it yet cause I was too lazy.
Zend_Controller_Router_Route: /article/:name $route->assemble(array('name' => 'foo & bar'));
Actual Output: /article/foo+&+bar
Expected Output (with default escape() settings): /article/foo+&+bar
Posted by Ben Scholzen (dasprid) on 2008-10-24T08:29:45.000+0000
Argh, wrongly escape...
Expected Output (with default escape() settings):
Posted by Ben Scholzen (dasprid) on 2008-10-24T08:30:24.000+0000 Ok now it gets stupid... Expected output: <pre class="highlight"> /article/foo+&+bar Posted by Jon Whitcraft (sidhighwind) on 2008-10-24T08:46:48.000+0000 Doing this would break BC as most people are already using the $this->escape() and it would double escape anything that they have already escaped. Posted by Ben Scholzen (dasprid) on 2008-10-24T10:21:06.000+0000 Then I mark this as fix for 2.0, as there we are able to break BC. Posted by Jon Whitcraft (sidhighwind) on 2008-11-10T18:15:02.000+0000 Moving this issue to be Unassigned as it's posponed till the 2.0 cycle as it would break BC. Posted by Ben Scholzen (dasprid) on 2008-11-13T02:11:39.000+0000 I found a solution to not have it as a BC-break, but instead as additional feature (until we clearify the default behaviour for 2.0): I'll add a static method Zend\_View\_Helper\_Url::setEscape(boolean $enable). By default it will have the old behaviour (of not escaping ULRs), but those who want that feature can enable it (e.g. in their bootstrap). I would also suggest an additional parameter in the Zend\_View\_Helper\_Url::url() method to set the escaping for a single call (null = default behaviour set by setEscape, false = don't escape, true = escape). I'll let Matthew review this before working on it. Posted by Matthew Weier O'Phinney (matthew) on 2008-11-18T10:55:41.000+0000 I see three solutions: \* Pass variables through escape() as you pass them to the helper (current method) \* Add an optional argument to the url() signature for "escape", allowing per-call escaping \* Have a static flag for setting the default behavior All of these are BC. Posted by Ralph Schindler (ralph) on 2011-02-18T14:33:03.000+0000 Should we postpone or move forward with one of Matthews proposed solutions? Posted by Ben Scholzen (dasprid) on 2011-02-19T03:57:45.000+0000 I'd say postpone it for 2.0 and make escaping be the default, but have an option to disable it. Posted by Pádraic Brady (padraic) on 2011-08-13T19:50:37.000+0000 Added Next Major Release as an affected version for filtering Posted by Adam Lundrigan (adamlundrigan) on 2011-10-17T19:33:23.000+0000 Should I resolve this ticket as 'Postponed' and clone it into ZF2, then?
Have you found an issue?
See the Overview section for more details.