I'm wanting to pull in some images from a remote URL which looks like they are controlled by some form of digital asset manager - and to make life difficult the images have no explicit file extension on them.
Examples:
http://bhs.scene7.com/is/image/BHS/1213193_a?$product294x250$
http://s7v1.scene7.com/is/image/Littlewoods/A911P_SP748_28_PU666?fmt=jpeg&qlt=90&wid=245&hei=410&color=255,255,255&size=245,410
Passing these remote image urls causes filefield_sources to throw back an error about no extension ("The remote URL must be a file and have an extension."). If no extension is found, can we not fall back to checking the HTTP headers before giving up? The above serve back with Content-Type:image/jpeg so the browser knows what to do with them.
I've not experimented yet, but maybe the adding of the extension could be done in remote.inc/_filefield_source_remote_filename() whilst its also getting the real filename from the HTTP headers?
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | filefield_sources_mimetype_extensions.patch | 2.22 KB | quicksketch |
| #10 | file_extension_from_mime-1221382-7.patch | 1.61 KB | budda |
| #4 | mimeheadertofileextension-1221382-4.patch | 2.72 KB | budda |
| #2 | mimeheadertofileextension-1221382-2.patch | 1.92 KB | budda |
Comments
Comment #1
buddaLooking at the code some more I see there is already some degree of support for extension-less URLs!
Looking at the headers coming back from the scene7.com image urls above there's no "real" filename specified in them so the module falls back to using the url, which also has no file extension.
Comment #2
buddaAttached is a patch to resolve the missing file extensions using the MIME header.
It just occurred to me that maybe I should have used the API function file_get_mimetype() ? It would cause a further file access though I believe.
Comment #3
clemens.tolboomwhitespace
No space before $filename.
Better use array(%file => $filename) within t function.
Comment #4
buddaRemoved the $filename debug as it was not needed.
Comment #5
giorgio79 commentedThis may help as well
http://drupal.org/project/allow_all_file_extensions, also somewhat related #1360004: Remove required file extension for remote url source - Or rename remote url to file.html if no extension specified
Comment #6
mnemyx commentedCould this patch also be available for the Drupal 6 version?
Comment #7
clemens.tolboomwhitespace (multiple times)
Why are these needed. You should document the reasons why.
You should add the url to the array as an placeholder for the t-function.
elseif should start on a new line.
space before the opening (
Comment #8
clemens.tolboomIsn't this a duplicate of #1182436: flickr: Only files with the following extensions are allowed ... when trying do get a flickr image. ?
Comment #9
buddaNo I think the two issues are different.
Flickr seems to be about catering for dodgy http headers with newslines.
This issue is about files with no extension falling back to using mime headers to add an extension on to the filename before saving.
Comment #10
buddaRe-rolled patch on a clean install and no debug / cruft from experimenting.
Comment #11
quicksketchThis patch should probably use file_mimetype_mapping() to lookup MIME-type/extension pairs and work with any extension, rather than being specific to image/* (which won't always line up with the extension exactly anyway).
Comment #12
quicksketchI've committed this patch based on budda's work that leverages Drupal's built-in MIME-type to extension mappings. Unfortunately because this mapping is not available to Drupal 6, we don't have the option to add this patch there also (though we could use budda's original approach perhaps). For now I've committed this to the 7.x-1.x branch only; it's probably time to leave D6 alone except for bug fixes anyway.