This test effectively tells the server that this request will contain no
data and any data in the body should be interpreted to be part of the
next request. By luck, we close the tcp connection beforehand so we
don't see this additional data. However, the issues caused here would
not be at the rgw/dho level.
This avoids a SAX/boto interaction bug that is not of much interest,
yet still seems "evil" enough that it fulfills the original intent
of the test.
Add a link to the relevant bug report.
The existing test_object_create_bad_md5_invalid is not valid
base64, and hence triggers a different code path. This time,
submit valid base64, but have the result not match the expected
md5sum.
Depending on the version of boto, different methods are necessary for
manipulating headers. We now support 2.0rc1 and 2.0 by sub-classing
boto.s3.connection.S3Connection and overloading
boto.connection.HTTPRequest.authorize, respectfully.
If a client specifies a range when requesting an object the server should
respond with 206 Partial Content when answering a request to get an object,
not 200 OK. It should also respond with only those bytes requested.
This commit introduces a test, test_ranged_request_response_code, that
checks those criteria.
When the owner has no grants on their bucket, they should not be able to
write to it, but still read and write the ACL. Amazon allows users to
read the bucket, and our behavior is consistent with this.
Accessing a non-constant global from another module is tricky,
as the import binds to the original object. Rebinding the name
in the original module does not change it in importers. Use a
getter as a quick workaround.
