hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11687) Ignore x-* and response headers when copying an Amazon S3 object
Date Tue, 29 Mar 2016 16:49:25 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216319#comment-15216319
] 

Steve Loughran commented on HADOOP-11687:
-----------------------------------------

There's no way to do add headers to the object except via reflection? In that case, we can
skip that; the s3x tests would benefit from more functional tests and test runs, really.

The reason they are all skipping is that it was causing problems on other s3 API infrastructures,
and there are other headers than just closed.

LGTM.

Harsh: I'll give you privilege of testing this, if you are happy then put it in

> Ignore x-* and response headers when copying an Amazon S3 object
> ----------------------------------------------------------------
>
>                 Key: HADOOP-11687
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11687
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs/s3
>    Affects Versions: 2.7.0
>            Reporter: Denis Jannot
>         Attachments: HADOOP-11687.001.patch
>
>
> The EMC ViPR/ECS object storage platform uses proprietary headers starting by x-emc-*
(like Amazon does with x-amz-*).
> Headers starting by x-emc-* should be included in the signature computation, but it's
not done by the Amazon S3 Java SDK (it's done by the EMC S3 SDK).
> When s3a copy an object it copies all the headers, but when the object includes x-emc-*
headers, it generates a signature mismatch.
> Removing the x-emc-* headers from the copy would allow s3a to be compatible with the
EMC ViPR/ECS object storage platform.
> Removing the x-* which aren't x-amz-* headers from the copy would allow s3a to be compatible
with any object storage platform which is using proprietary headers



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message