Adding &response-content-disposition:attachment to presigned URL causing error

[V Roop]

<Error message-
<Error>
<Code>InvalidArgument</Code>
-
<Message>
response-content-disposition:attachment is not in the set of
overridable response headers. Please refer to the S3 API documentation
for a complete list of overridable response headers.
</Message>
<ArgumentValue/>
<ArgumentName>response-content-disposition:attachment</ArgumentName>

I am using jets3t-0.7.1 version.

List of overriden response headers -
http://docs.amazonwebservices.com/AmazonS3/latest/API/index.html?RESTObjectGET.html

Any idea what is causing this error?

Thanks

[James Murty]

It looks like the argument name you are using also includes the value,
it has the suffix ":attachment" which doesn't look right. This should
be a GET parameter and value, see the examples on the Amazon
documentation page you linked to.

James

> --
> You received this message because you are subscribed to the Google Groups "JetS3t Users" group.
> To post to this group, send email to jets3t...@googlegroups.com.
> To unsubscribe from this group, send email to jets3t-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jets3t-users?hl=en.
>
>

[V Roop]

Thanks for the response. I don't know how to set get parameters right
to make it work.
I am creating signed URL using S3Service.createSignedGetUrl and then
appending response.sendRedirect(uri+"&response-content-
disposition=attachment");
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you
provided. Check your key and signing method.
</Message>
<StringToSign>
GET
4535353234
/MyBucket/blahblah.png?response-content-disposition=attachment
</StringToSign>

Do I need to use different jets3t api to create signed url?

On Jun 15, 7:16 pm, James Murty <jamu...@gmail.com> wrote:
> It looks like the argument name you are using also includes the value,
> it has the suffix ":attachment" which doesn't look right. This should
> be a GET parameter and value, see the examples on the Amazon
> documentation page you linked to.
>
> James
>
>
>
>
>
>
>
> On Wed, Jun 15, 2011 at 3:07 PM, V Roop <roopv2...@gmail.com> wrote:
> > <Error message-
> > <Error>
> > <Code>InvalidArgument</Code>
> > -
> > <Message>
> > response-content-disposition:attachment is not in the set of
> > overridable response headers. Please refer to the S3 API documentation
> > for a complete list of overridable response headers.
> > </Message>
> > <ArgumentValue/>
> > <ArgumentName>response-content-disposition:attachment</ArgumentName>
>
> > I am using jets3t-0.7.1 version.
>
> > List of overriden response headers -

> >http://docs.amazonwebservices.com/AmazonS3/latest/API/index.html?REST...

[James Murty]

I'm not too familiar with these response-altering parameters but I
expect you need to include the parameter in the URL before you sign
it, rather than adding it on afterwards.

S3 expects the signed URL to include all the parameters it sees when
it receives the request. So try appending the extra parameter before
you call S3Service#createSignedGetUrl.

[James Murty]

I followed up on this and did some testing which showed that JetS3t
did not support signing of these kinds of requests, since it ignored
the unrecognized new parameter names like "response-content-type".

I have applied a fix for this:
https://bitbucket.org/jmurty/jets3t/changeset/06fa45d3ee4e

To correctly sign a request of this kind you will need to use the
#createSignedUrl signing method and pass in the extra parameters as
the "specialParamName" argument, like so:

String signedGetUrl = s3Service.createSignedUrl("GET",
bucketName, objectName,

"response-content-type=text/plain&response-content-encoding=latin1",
null, // No headers
(expiryDate.getTime() / 1000) // Expiry time after
epoch in seconds
);

Hope this helps,
James

[V Roop]

Thanks James.

On Jun 16, 7:59 pm, James Murty <jamu...@gmail.com> wrote:
> I followed up on this and did some testing which showed that JetS3t
> did not support signing of these kinds of requests, since it ignored
> the unrecognized new parameter names like "response-content-type".
>
> I have applied a fix for this:https://bitbucket.org/jmurty/jets3t/changeset/06fa45d3ee4e
>
> To correctly sign a request of this kind you will need to use the
> #createSignedUrl signing method and pass in the extra parameters as
> the "specialParamName" argument, like so:
>
>             String signedGetUrl = s3Service.createSignedUrl("GET",
> bucketName, objectName,
>
> "response-content-type=text/plain&response-content-encoding=latin1",
>                 null, // No headers
>                 (expiryDate.getTime() / 1000) // Expiry time after
> epoch in seconds
>                 );
>
> Hope this helps,
> James
>
>
>
>
>
>
>
> On Thu, Jun 16, 2011 at 6:17 PM, James Murty <jamu...@gmail.com> wrote:
> > I'm not too familiar with these response-altering parameters but I
> > expect you need to include the parameter in the URL before you sign
> > it, rather than adding it on afterwards.
>
> > S3 expects the signed URL to include all the parameters it sees when
> > it receives the request. So try appending the extra parameter before
> > you call S3Service#createSignedGetUrl.
>