File component double-encodes private file URLs in e-mails [#904806]

I have a client for which I use webform to allow people to apply for employment positions. when I allow users to attach their resume's to the form submission, everything works fine, until HR tries to access the resume file attachment via the emailed link or the link in the submission results for the form.

What is happening is that drupal is swapping spaces in the url for the encoded value of %20, but the line 586 of components/file.inc is setting the url value differently...

$file_url = file_create_url($info['dirname'] .'/'. rawurlencode($info['basename']))

Sets the value of a space in the url as %2520

When I remove the function call to rawurlencode I see that the code works much better.

can I submit a patch for this and get you guys to make the change into the code base?

Thanks,

Comment	File	Size	Author
#10	904806-webform-do-not-escape-private-files.patch	925 bytes	Dave Reid
#10
#9	904806-webform-do-not-escape-private-files.patch	925 bytes	Dave Reid
#9
#1	file.inc_.patch	543 bytes	jadowd
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

jadowd CreditAttribution: jadowd commented 7 September 2010 at 22:10

File	Size
file.inc_.patch	543 bytes

Here is the patch!

Comment #2

quicksketch

he/him

CreditAttribution: quicksketch commented 7 September 2010 at 22:16

Title:

url generation for file component is broken

» File component double-encodes URLs in e-mails

Something tells me this is going to fix it in one place but break it in another. I bet this will make links in e-mails work (since they're plain text) but break it when the submission is viewed in a web browser.

Comment #3

jadowd CreditAttribution: jadowd commented 8 September 2010 at 02:10

I have tested in both places... it was broken in both places. It seemed to me that the URL was being parsed twice or something.

If you have a better solution, I am totally amicable.

Comment #4

quicksketch

he/him

CreditAttribution: quicksketch commented 8 September 2010 at 02:21

Hm strange, I'm sure that urlencode() was put there for a reason. Perhaps a change in Drupal core has made it unnecessary.

Comment #5

jadowd CreditAttribution: jadowd commented 8 September 2010 at 13:06

it was rawurlencode... and, I think that you may be right. My guess is that the function call "file_create_url" may have something to do with it...

Comment #6

quicksketch

he/him

CreditAttribution: quicksketch commented 23 February 2011 at 23:29

Version:

6.x-2.9

» 6.x-3.6

This call to rawurlencode() still exists in the 3.x version, though I'm still uncertain about this change. This won't be fixed in the 2.x version so I'm moving to the latest version.

Comment #7

quicksketch

he/him

CreditAttribution: quicksketch commented 23 February 2011 at 23:34

Title:	File component double-encodes URLs in e-mails	» File component double-encodes private file URLs in e-mails
Status:	Active	» Postponed

So it looks to me like we're doing the right thing if the file is a public file, but the double-encoding would only happen if you have the private file system enabled (admin/settings/file-system). Public files are not escaped but private files are run through url(), which ultimately calls drupal_encodeurl().

Considering many more users use public files than private files (and with good reason, private files are really, really slow), I think it's a good idea to hold-off on this change. If we can come up with a universal solution I'd be happy to hear it, but for now I think I'd recommend any of the following:

- Install the transliteration.module, which will make safe-names for your uploaded files and prevent this situation.
- Use public files instead of private files.