On Thu, Apr 12, 2018 at 01:41:38PM -0000, [email protected] wrote: > Additional information on this issue: I've discovered by virtue of a > wireshark session that jclouds client is NOT sending chunked > transfer-encoding, but rather aws-chunked content-encoding. Can anyone tell > me why this is necessary, since A) it accomplishes the same thing that > chunked transfer-encoding does (except that it's not compatible with most web > servers' built-in ability to handle chunked encoding) and B) we're sending > the content-length header?
aws-s3 uses V4 signing while s3 uses V2 signing. V4 uses a chunked encoding to sign the payload as well as the headers while V2 signs only the headers. V4 uses the AWS encoding because of the signatures it attaches. I believe you can Guice override the signer type in s3 to get the same behavior as aws-s3. If you are using a local S3 clone and not AWS itself you really should use the s3 provider since aws-s3 just overrides endpoints and regions. I notice you filed a related bug against s3ninja recently -- you may want to try S3Proxy[1] instead which has a more complete implementation and actually uses jclouds as its backend. [1] https://github.com/gaul/s3proxy -- Andrew Gaul http://gaul.org/
