Support actions via presigned urls about s3rver HOT 3 CLOSED

This just means that we need to support options and metadata specified through query parameters instead of headers right? What happens to metadata specified through HTTP headers? I'm guessing that normally S3 responds with a 403 because the signature won't match, but we don't do signing yet.

from s3rver.

Hey, I finally had some time to research (and look into implementing) this, but I think the specific example you gave with Content-Type doesn't actually work due to how request signing works. Omitting custom metadata works fine, but traditional headers (like Content-Type or Content-Disposition) must be specified as headers or else S3 will throw SignatureDoesNotMatch.

Anyway, if this sounds incorrect let me know. My plan is do perform faux-signature matching by ensuring that the metadata specified in query params match those specified in headers, with the exception of omitted x-amz-* headers.

from s3rver.

This is actually more nuanced than I expected. So far I've determined the following behavior (most of it can be derived from here):

For a field in the query params starting with x-amz-*

• use the value specified in the query params, ignore matching fields specified in the request headers

For a field in the query params or request headers not starting with x-amz-* (except for Content-Type and Content-MD5)

• (interestingly) completely ignore them in signature verification
  • AWS doesn't include these headers when calculating the signature since adding/removing these fields from both query params and headers has no effect on the validity of the signature

For Content-MD5 and Content-Type in query params

• values are ignored, AWS will only consider the values specified in request headers
• reports SignatureDoesNotMatch if there isn't an exact match in the request headers
  • This includes omitting the header if the signature is calculated without Content-Type header

For a field in the request headers starting with x-amz-*

• only report a mismatch if it was present in the signed canonical request but not included as a query param
• ignore the value if the field is present as a query param

Once this is done I'll probably open a new issue tracking proper verification of request signatures.

from s3rver.