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 |
#9 | 904806-webform-do-not-escape-private-files.patch | 925 bytes | Dave Reid |
#1 | file.inc_.patch | 543 bytes | jadowd |
Comments
Comment #1
jadowd CreditAttribution: jadowd commentedHere is the patch!
Comment #2
quicksketchSomething 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 commentedI 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
quicksketchHm 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 commentedit 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
quicksketchThis 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
quicksketchSo 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.
Comment #8
kim.pepperI get this issue in emails (both plain and html) when using public files. Links to files are double-encoding spaces.
K
Comment #9
Dave ReidPatch attached to fix this issue for users of private files only. Does not apply to 7.x-3.x.
Comment #10
Dave ReidComment #11
quicksketchThanks Dave, committed finally.
Comment #13
rterrero CreditAttribution: rterrero commented#9 was perfect for me.
Thanks!