for some remote sources, notably amazon.com images in my case, the remote source does not process images correctly. an example of a URL that did not work for me is: http://ecx.images-amazon.com/images/I/31KxrPhLIoL.jpg. This file can be downloaded normally through the browser and through curl, but is mangled by the URL transfer process. Downloading the file, and then uploading it works fine. Upon examination of the image file, I discovered that the module is prepending http response header directly into the jpeg file, rendering it unreadable as an image. I manually removed this header information, and the image became readable. below is what I found inside the jpeg file, as processed by this module:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 15533
Connection: keep-alive
Server: nginx
Date: Sat, 08 Mar 2014 08:22:17 GMT
nnCoection: close
Cache-Control: max-age=630720000,public
Expires: Wed, 18 May 2033 03:33:20 GMT
Last-Modified: Fri, 21 Feb 2014 20:06:29 GMT
Age: 210060
X-Cache: Hit from cloudfront
Via: 1.1 5a188b5fcd589800ba90a8002a8c728c.cloudfront.net (CloudFront)
X-Amz-Cf-Id: _PfGDV-xRwh2z8k5q_qFKzZ3rWK5o-e34ofJXIpUppKzyzUzyK-hGw==

ˇÿˇ‡

etc, in binary.

Update: clearing the browser cache may have allowed me to transfer the file correctly, one time, until the image was in my cache again. This seems strange, since with remote add, my browser cache should be entirely irrelevant, but I thought I would mention it. a copy of my mangled file is attached.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jvsteiner’s picture

it seems that in some cases, the response to curling the headers is not 200, however when the file is subsequently retrieved using HTTPGET, the header information still comes through. Although it's still unclear to me why this would be the case, adding the following after line 150 in remote.inc seems to alleviate the problem for me:

curl_setopt($ch, CURLOPT_HEADER, FALSE);

thoughts on what other impacts this might have?

jvsteiner’s picture

I went to make a patch, but I see the relevant portion of code in the repository has been restructured, and I believe this problem should no longer occur in the next version.

w.drupal’s picture

Version: 7.x-1.9 » 7.x-1.11
Status: Active » Needs review
FileSize
473 bytes
164.63 KB

Still not working for me when trying to upload the image from https://collectionapi.metmuseum.org/api/collection/v1/iiif/486014/101047.... I attached the image obtained after uploading, just as an example.

curl_setopt($ch, CURLOPT_HEADER, FALSE); helped me