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.

Comments

gerhard killesreiter’s picture

Project: Drupal.org infrastructure » Project issue tracking
Version: » 5.x-2.x-dev
Component: Other » Issues

movin

aclight’s picture

I 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.

ztyx’s picture

Project: Project issue tracking » Drupal core
Version: 5.x-2.x-dev » 6.4
Component: Issues » upload.module

[...] I suspect this is a bug in either the core upload module or the comment_upload module

Yes, you are right. I just confirmed this bug in Drupal version 6.4 using the core upload module.

ztyx’s picture

Title: Attaching files with number sign (#) results in broken link » Attaching files with [#?]-characters results in broken link
Status: Active » Needs work
StatusFileSize
new749 bytes

This 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.

ztyx’s picture

Assigned: Unassigned » ztyx
Priority: Normal » Critical
Status: Needs work » Needs review
StatusFileSize
new695 bytes

Ah, 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.

ztyx’s picture

Assigned: ztyx » Unassigned
Anonymous’s picture

Status: Needs review » Needs work

Should use drupal_urlencode instead.

ztyx’s picture

Status: Needs work » Needs review
StatusFileSize
new699 bytes

Ah. Thanks. Attaching a new patch.

Babalu’s picture

thx

aclight’s picture

Version: 6.4 » 7.x-dev
Component: upload.module » file system

The 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.

aclight’s picture

Status: Needs review » Needs work

I 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.

function drupal_urlencode($text) {
  if (variable_get('clean_url', '0')) {
    return str_replace(array('%2F', '%26', '%23', '//'),
                       array('/', '%2526', '%2523', '/%252F'),
                       rawurlencode($text));
  }
  else {
    return str_replace('%2F', '/', rawurlencode($text));
  }
}

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.

drewish’s picture

Status: Needs work » Closed (duplicate)