ZF-11669: Zend_Service_Amazon_S3::copyObject is not working

Issue Type: Bug Created: 2011-08-15T22:48:45.000+0000 Last Updated: 2012-12-04T16:41:24.000+0000 Status: Open Fix version(s): Reporter: Thiago Flessak (tflessak) Assignee: Enrico Zimuel (zimuel) Tags: - Zend_Service_Amazon

Related issues: - ZF-11030



After debugging I found out that the problem is related with Zend_Http_Client:

<pre class="literal"> 
if (($method == self::POST || $method == self::PUT || $method == self::DELETE) && $this->enctype === null) {

As copyObject executes a PUT request, I realized that encType can't be URLENCODED.


Posted by Ramon Henrique Ornelas (ramon) on 2011-08-16T14:24:38.000+0000

Related with ZF-11030 see r24269

Posted by Thiago Flessak (tflessak) on 2011-08-16T14:40:56.000+0000

This issue started after 1.11.10, as long as I know, the ZF 11030 path was applied in this version, consequently, it broke other services.

Posted by Adam Plumb (adamplumb) on 2011-09-09T15:05:42.000+0000

I just found this ticket after running into this bug myself. I'm using 1.11.10 and copyObject isn't working because the signatures aren't matching. This seems to be because of a urlencoding issue.

Posted by Thiago Flessak (tflessak) on 2011-09-30T14:43:21.000+0000

I can confirm it is related with ZF 11030. After this path, the content-type header is always set if not explicity defined. The problem is that for copy operation, if content-type was specified, Amazon S3 expects that it were included in auth header signature.

I propose the follow path:

<pre class="literal">
--- S3.php (revision 24083)
+++ S3.php (working copy)
@@ -524,10 +524,12 @@
         $sourceObject = $this->_fixupObjectName($sourceObject);
         $destObject   = $this->_fixupObjectName($destObject);
+        $sourceInfo = $this->getInfo($sourceObject);
         $headers = (is_array($meta)) ? $meta : array();
         $headers['x-amz-copy-source'] = $sourceObject;
         $headers['x-amz-metadata-directive'] = $meta === null ? 'COPY' : 'REPLACE';
+        $headers['Content-type'] = $sourceInfo['type'];
         $response = $this->_makeRequest('PUT', $destObject, null, $headers);

This way, content-type header is explicity defined as the same of original object. In my tests, this issue doesn't affect other operations.

Posted by Vladimir Grigor (voukka) on 2012-01-05T16:25:44.000+0000

I confirm that Thiago's patch works for me.

Posted by Jan Hapke (hopka) on 2012-02-01T21:51:55.000+0000

Thiago's patch would force the Content-type header to the Content-type of the source object and make it impossible to change the Content-type during the copy operation by passing the $meta array.

I suggest to only add the header if it is not already specified in the $meta array.

Posted by J B (dubnut) on 2012-05-15T05:11:03.000+0000

Came up against this tonight while using 1.11.10. Upgraded to 1.11.11 and still had the problem. Rolled back to an old 1.11.4 just cuz it was there, and the S3 moveObject + copyObject calls started to work again... Point being: Appears to be a problem in .10 + 1.11.11

Posted by Michael Reid (mikereid79) on 2012-12-04T16:41:24.000+0000

I encountered this problem today in the latest build from Zend. This can be coded around though, rather than using a patch.

<pre class="highlight"> 
$s = $s3->getInfo($source);
$meta['Content-type'] = $s['type'];
return $this->getS3()->copyObject($source, $destination, $meta); 

Hope this helps.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.