Percent signs don't get escaped on URLs

[anonymous]

Filenames like 'some%20test.png' (where %20 is really a part of the filename, not a space) don't get escaped when linked to.

This results in links like '<a href="/some%20test.png">' instead of '<a href="/some%2520test.png">'.

---

Moved from SF:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1600426&group_id=75348&atid=543653

[Frederico Caldeira Knabben]

Confirmed with both IE and FF.

The thing to note is that this is a File Browser strict thing. We don't have to encode URLs typed in the dialogs. The File Browser instead must send then correctly encoded when filling the dialog fields.

[Alfonso Martínez de Lizarrondo]

I'm doing some test just using escape() before calling the setUrl and it seems to generate the correct output to fix this bug as well as #511 and #261 (targeted to 2.5 but I think that the three are in fact the same bug)

But the reality is that escaping that way the urls only works to fix the space problem of #261, I'm not able to find out how to generate a url for a special sign that works with this IIS.

I'm attaching the patch (it does include other cleanup that I did for #454) so it can be tested, maybe this is only a problem in this server and it does fix the problem for other servers.

[Alfonso Martínez de Lizarrondo]

work in progress

[Frederico Caldeira Knabben]

encodeURI() did the trick.

Fixed with [342].

Click here for more info about our SVN system.

[Alfonso Martínez de Lizarrondo]

I've found out why my tests wasn't successful:

I was using the PHP connector to upload the images and browse the server, but with the default configuration, so it was using a physical path different than the one mapped to /userfiles/ in the server and so any new files (the ones that I uploaded with special characters) can't be reached with the server.

And anyway, the PHP connector does have a bug because it did uploaded the files to a whole new directory: /FCKDe/userfiles eating the last "d" in FCKdev (it would still be a non public directory, but at least it should be using some real directory to create the /userfiles/. I'll file a ticket if I'm able to reproduce the bug and make sure that it isn't my fault.