ASF GitHub Bot logged work on HDDS-1948:

                Author: ASF GitHub Bot
            Created on: 21/Aug/19 08:30
            Start Date: 21/Aug/19 08:30
    Worklog Time Spent: 10m 
      Work Description: elek commented on pull request #1266: HDDS-1948. S3 MPU 
can't be created with octet-stream content-type 
URL: https://github.com/apache/hadoop/pull/1266#discussion_r316050595

 File path: 
 @@ -17,39 +17,58 @@
 package org.apache.hadoop.ozone.s3;
+import javax.annotation.Priority;
 import javax.ws.rs.container.ContainerRequestContext;
 import javax.ws.rs.container.ContainerRequestFilter;
 import javax.ws.rs.container.PreMatching;
 import javax.ws.rs.core.MediaType;
+import javax.ws.rs.core.MultivaluedMap;
 import javax.ws.rs.ext.Provider;
 import java.io.IOException;
  * Filter to adjust request headers for compatible reasons.
+ *
+ * It should be executed AFTER signature check (VirtualHostStyleFilter).
 Review comment:
   > Is this priority setting is done, to perform this Preprocessing after 
VirtualHostStyleFilter processing. (Is there any reason to do in this order?)
   Yes, the Content-Type headers can be part of the headers which are part of 
the signature. Therefore we need to check the signature first and modify the 
Content-Type header after.
    >  Can we define these constants and use them, instead of hardcoded values.
   Well, it's random value anyway and used only in this one place ;-) But I 
improved it with constants to express the dependencies:
       + S3GatewayHttpServer.FILTER_PRIORITY_DO_AFTER)
   public class HeaderPreprocessor implements ContainerRequestFilter {
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

Issue Time Tracking

    Worklog Id:     (was: 298515)
    Time Spent: 2h  (was: 1h 50m)

> S3 MPU can't be created with octet-stream content-type 
> -------------------------------------------------------
>                 Key: HDDS-1948
>                 URL: https://issues.apache.org/jira/browse/HDDS-1948
>             Project: Hadoop Distributed Data Store
>          Issue Type: Bug
>          Components: S3
>            Reporter: Elek, Marton
>            Assignee: Elek, Marton
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 2h
>  Remaining Estimate: 0h
> This problem is reported offline by [~shaneku...@gmail.com].
> When aws-sdk-go is used to access to s3 gateway of Ozone it sends the Multi 
> Part Upload initialize message with "application/octet-stream" Content-Type. 
> This Content-Type is missing from the aws-cli which is used to reimplement s3 
> endpoint.
> The problem is that we use the same rest endpoint for initialize and complete 
> Multipart Upload request. For the completion we need the 
> CompleteMultipartUploadRequest parameter which is parsed from the body.
> For initialize we have an empty body which can't be serialized to 
> CompleteMultipartUploadRequest.
> The workaround is to set a specific content type from a filter which help up 
> to create two different REST method for initialize and completion message.
> Here is an example to test (using bogus AWS credentials).
> {code}
> curl -H 'Host:yourhost' -H 'User-Agent:aws-sdk-go/1.15.11 (go1.11.2; linux; 
> amd64)' -H 'Content-Length:0' -H 'Authorization:AWS4-HMAC-SHA256 
> Credential=qwe/20190809/ozone/s3/aws4_request, 
> SignedHeaders=content-type;host;x-amz-acl;x-amz-content-sha256;x-amz-date;x-amz-storage-class,
>  Signature=7726ed63990ba3f4f1f796d4ab263f5d9c3374528840f5e49d106dbef491f22c' 
> -H 'Content-Type:application/octet-stream' -H 'X-Amz-Acl:private' -H 
> 'X-Amz-Content-Sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
>  -H 'X-Amz-Date:20190809T070142Z' -H 'X-Amz-Storage-Class:STANDARD' -H 
> 'Accept-Encoding:gzip' -X POST 
> 'http://localhost:9999/docker/docker/registry/v2/repositories/apache/ozone-runner/_uploads/2173f019-09c3-466b-bb7d-c31ce749d826/data?uploads
> {code}
> Without the patch it returns with HTTP 405 (Not supported Media Type).

This message was sent by Atlassian Jira

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to