The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.It'd be wonderful if the remote URL source would accept URLs which, while not looking like a file source, do provide a filename in the Content-Type or Content-Disposition header.
For example, if I download http://ga.berkeley.edu/filedepot_download/275/209, my browser automatically determines that the proper file name is Delegates_101104_agenda_0.pdf because the server returns the headers
Content-Disposition: attachment; filename="Delegates_101104_agenda_0.pdf"
Content-Type: application/pdf; name="Delegates_101104_agenda_0.pdf"
The $filename variable could easily be overridden by the name attribute of Content-Type, which could be extracted from $info['content_type'] in remote.inc.
Comments
Comment #1
bfroehle commentedSince
Cotent-Typeis much easier to extract from cURL thanContent-Disposition, attached is a patch which trusts the server provided filename as long asContent-Typehas the form...name="{filename}"....Comment #2
quicksketchThanks! What a great idea. I'd be happy to include this feature. I think it could use a few lines of comments on what's going on here, but otherwise looks great. We don't normally use named placeholders in regexs, so for consistency it'd probably be good to replace
?P<filename>.+?with just .+? and refer to it later as $matches[1].Comment #3
bfroehle commented@quicksketch: Here's an updated patch that removes the named placeholder in the regex and adds some comments.
Comment #4
quicksketchPerfect! I'll give this a test and if it works as advertised I'll include it and make sure it's in the next release.
Comment #5
bfroehle commentedEven better! I whipped up a new patch which uses the Content-Disposition field to read the filename. Note that I've chosen to do this in lieu of checking the Content-Type field, as I've generally found the name in Content-Type to be redundant.
Also the regular expression should be more robust to allow for filename specification of the form
filename="FILENAME WITH SPACES.EXT"orfilename=FILENAME.EXT.Comment #6
quicksketchI know it's been ages (we haven't had any releases in a long, long time). I'll still review this and include in the 1.3 release.
Comment #7
quicksketchI've committed the attached patches to the project. It's the same approach @bfroehle provided only I swapped the use of a global variable for a get/set function with a static variable.
Comment #9
nonsimilar commentedSorry to reopen an old issue without posting a patch, but it's really a minor fix:
the two preg_match() in _filefield_source_remote_parse_header() should really be case-insensitive as sometimes the server returns "content-disposition" and not "Content-Disposition" (e.g. Dropbox).
Comment #12
quicksketchThanks @nonsimilar. I've made the preg_match use the insensitive flag.