byterock

Well still in clean-up mode here in the Paws Pen trying to get the full t/10_response.t test case working.

I was having all sorts of fun with the 'GetBucketPolicy' action test. By fun I mean a good hour of frustration and cursing and gnashing of teeth as my real-time test script was working fine! I just could not get the test in 's3-get-bucket-policy.response.test.yml' to pass.

Then I stumbled on it.

This is the one very odd action on the AWS S3 API where it dose not return XML but returns JSON. Now I do handle this with this code

       } elsif (exists($headers->{'content-type'})
               and $headers->{'content-type'} eq 'application/json'
               and $ret_class->can('_payload')){
        $unserialized_struct->{$ret_class->_payload} = $content;

in RestXMLResponse.pm.

In the data for the test found in ' s3-get-bucket-policy.response' ;

content: |
   {"Version":"2012-10-17","Statement":[{"Sid":"AddPerm","Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::bucket-name/*"}]}
headers: []

I had empty for the headers and as a result when processing the canned response it was not hitting the above snippet of code from RestXMLResponse.pm. Therefor It would not properly process this silly one off.

I just added in the correct header to the test;

--headers: []
++headers:
++    - content-type: application/json

and it passed!

So did a switch to the main stream Boto code base, pulled it down and then re-compiled my auto-generated code just to be 110% sure I had no more changes in my Paws code that was dependent on changes to boto.

When I ran the test suite I found I still must have had one more 'boto' change to pull out. I was getting this from the test suite;

missing required header for this request: Content-MD5

Seems I am back to that 'PutBucketLifecycleConfiguration' bug that was solved by a change to boto.

I did check the API for this and it does not say that 'Content-MD5' is the required , however it does have it in all the requests examples;

PUT /?lifecycle HTTP/1.1
Host: examplebucket.s3.amazonaws.com 
x-amz-date: Wed, 14 May 2014 02:11:21 GMT
Content-MD5: q6yJDlIkcBaGGfb3QLY69A==
Authorization: authorization string
Content-Length: 415

By way of contrast the very similar PutBucketLogging call does have it;

URI Request Parameters The request requires the following URI parameters.

• Bucket

The name of the bucket for which to set the logging parameters.

• Content-MD5

The MD5 hash of the PutBucketLogging request body.

It seems in other posts and blogs there have been words on this one before. So I complained about this to the document maintainer of AWS. No response on this one after a few days. I even made a bug report on boto.

Though I do not think we will see any action on that one either.

There is a simple if inelegant kludge for this by just adding this

has ContentMD5 => (is => 'ro', isa => 'Str', header_name => 'Content-MD5', auto => 'MD5', traits => ['AutoInHeader'] );

to the 'restxml/callargs_class.tt' template so all calls have it. For good measure I added this in

[% FOREACH param_name IN shape.members.keys.sort -%]
++    [% NEXT IF param_name == 'ContentMD5' %]

So there are no genrated cases with two ContentMD5 attributes on them.

I added this in and so far ASW is not complaining about having that attribute in the header so now all my tests ported over from my other branches are working with no changes to boto. This time for sure.