I attached a file containing the number sign (#) the other day to an issue. The upload seem to succeed but in the link to the attachment was not converted and was instead refering to something like "file#.patch", which obviously was a broken link.
I'm attaching a very small file containing the number sign with this issue as a proof of concept.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | upload.core-issue312354-fix-broken-link-characters3.patch | 699 bytes | ztyx |
| #5 | upload.core-issue312354-fix-broken-link-characters2.patch | 695 bytes | ztyx |
| #4 | upload.core-issue312354-fix-broken-link-characters.patch | 749 bytes | ztyx |
| testfile#.txt | 21 bytes | ztyx |
Comments
Comment #1
gerhard killesreiter commentedmovin
Comment #2
aclight commentedI don't have the time to investigate this now, but I suspect this is a bug in either the core upload module or the comment_upload module, since that's what project_issue uses to handle uploads.
Comment #3
ztyx commentedYes, you are right. I just confirmed this bug in Drupal version 6.4 using the core upload module.
Comment #4
ztyx commentedThis bug also occurs for question marks (?).
I also tried the '&'-character and it works without a problem.
I am attaching a patch that fixes my reported problems (specifically number sign and question mark). The patch needs work as it is not generalized for other characters that might break the URL (are there other?). Ultimately it shouldn't encode only these two characters, but all using urlencode() or similar. urlencode() breaks the URL though, for some reason I'm trying to figure out.
If anyone is interested helping out a test case for this would be great to know which filenames are good and which are not.
Comment #5
ztyx commentedAh, urlencode() was not the correct function to call, it should have been rawurlencode().
I'm attaching a patch that escapes all characters so that no broken link occurs, and therefor should solve this issue.
The patch is tested against filenames containing #, & and ? using both the public and the private download methods.
I am also making this issue critical, as it actually breaks the functionality of upload.core module. When you think you've uploaded a file, and it's not reachable, I consider it broken.
Comment #6
ztyx commentedComment #7
Anonymous (not verified) commentedShould use drupal_urlencode instead.
Comment #8
ztyx commentedAh. Thanks. Attaching a new patch.
Comment #9
Babalu commentedthx
Comment #10
aclight commentedThe bug is in file_create_url(), and that function hasn't changed in HEAD, so though I haven't tested I would expect this to also be a problem in HEAD. Therefore, I'm changing the version so that we can get it fixed in HEAD and then backport.
Comment #11
aclight commentedI confirmed that this problem exists in HEAD as well.
Unfortunately, the patch in #8 does not fix the problem in all cases, specifically when clean_urls are *enabled* on a site. This is because drupal_urlencode() returns different values depending on whether or not clean_urls are enabled.
If in the patch I replaced drupal_urlencode() with a call to urlencode(), I get the correct behavior both when clean_urls are enabled or disabled.
To test I am just creating a text file named #test.txt, and uploading that as an attachment to a page node. Without any patch, clicking on the download link on the node leads to a page not found error. With the patch in #8 applied, when clean_urls are enabled I still get a page not found, but when they are disabled I get the actual text file itself.
Comment #12
drewish commentedsee #238299: file_create_url should return valid URLs