Ticket #182 (closed Bug: fixed)

Opened 3 years ago

Last modified 3 years 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 Download (2.7 KB) - added by alfonsoml 3 years ago.
work in progress

Change History

Changed 3 years ago by fredck

  • reporter changed from fredck to anonymous

Changed 3 years 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 3 years ago by fredck

  • milestone set to FCKeditor 2.4.3

Changed 3 years 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 3 years ago by alfonsoml

work in progress

Changed 3 years 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 3 years 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.