Zend Framework

Zend_Service_Amazon_S3::copyObject is not working

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.11.10
  • Fix Version/s: None
  • Component/s: Zend_Service_Amazon
  • Labels:
    None

Description

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

 
if (($method == self::POST || $method == self::PUT || $method == self::DELETE) && $this->enctype === null) {
    $this->setEncType(self::ENC_URLENCODED);
}

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

Issue Links

This issue is related to:
ZF-11030 Content-type set per default with PUT to '' has for consequence that Zend_Rest_Client PUT can't work Blocker Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ramon Henrique Ornelas added a comment - - edited

Related with ZF-11030 see r24269

Show
Ramon Henrique Ornelas added a comment - - edited Related with ZF-11030 see r24269
Hide
Permalink
Thiago Flessak added a comment -

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.

Show
Thiago Flessak added a comment - 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.
Hide
Permalink
Adam Plumb added a comment -

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.

Show
Adam Plumb added a comment - 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.
Hide
Permalink
Thiago Flessak added a comment -

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:

--- 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.

Show
Thiago Flessak added a comment - 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: 
--- 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.
Hide
Permalink
Vladimir Grigor added a comment -

I confirm that Thiago's patch works for me.

Show
Vladimir Grigor added a comment - I confirm that Thiago's patch works for me.
Hide
Permalink
Jan Hapke added a comment -

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.

Show
Jan Hapke added a comment - 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.
Hide
Permalink
J B added a comment -

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

Show
J B added a comment - 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

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.