Ticket #182 (closed Bug: fixed)

Opened 17 months ago

Last modified 14 months ago

Percent signs don't get escaped on URLs

Reported by: anonymous Owned by:
Priority: Normal Milestone: FCKeditor 2.4.3
Component: File Browser Version: FCKeditor 2.3.2
Keywords: SF Confirmed Cc:

Description

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

Attachments

escape urls.patch (2.7 kB) - added by alfonsoml 14 months ago.
work in progress

Change History

Changed 17 months ago by fredck

  • reporter changed from fredck to anonymous

Changed 17 months ago by fredck

  • keywords Confirmed added

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.

Changed 14 months ago by fredck

  • milestone set to FCKeditor 2.4.3

Changed 14 months ago by alfonsoml

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.

Changed 14 months ago by alfonsoml

work in progress

Changed 14 months ago by fredck

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

encodeURI() did the trick.

Fixed with [342].

Click here for more info about our SVN system.

Changed 14 months ago by alfonsoml

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.

Note: See TracTickets for help on using tickets.