As recommended at
http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html:
"You can also send a signature as a URL-encoded query-string parameter
in the URL for the request."
Also deals with some of the craziness of URL encoding/decoding in
jclouds.
References JCLOUDS-200
Introduces AWSS3BlobRequestSigner, which reuses the
RequestAuthorizeSignature filter for most of the heavy lifting.
Other implementation details based on [1].
Tested with AWSS3BlobSignerLiveTest, in particular,
testSign(Get|Put)UrlWithTime.
Closes JCLOUDS-200
[1] http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
- ACS 4.x doesn't like taking SSH pub keys from the filesystem, so
generate them on the fly.
- vm.getDisplayName() can be null now.
- Add new possible resource limit types.
- Default to looking template=osFamily=CENTOS, since that's the only
template guaranteed to be there in the simulator.
- Use adminJobComplete instead of jobComplete in admin tests
- Accept capacity/usage/etc of 0.
- Premium configuration category not present in ACS.
- Sleep a bit between deleting a domain and verifying it's not there
any more. Also expect an IllegalStateException.
- Given that there are issues deleting zones at the moment (through
the UI, too), use a different zone for pod and zone tests.
Still failing tests:
- pretty much everything that creates a VM and expects to log into it,
but that's simulator-specific.
- Zone deletion, due to a bug in ACS, apparently.
- Registering and creating templates
- creating volumes from snapshots, and attaching volumes
Large blob support for AzureClient; the next step of this is to
support PutOptions.multipart and digest a blob into 4M parts. This
just implements the Azure interaction.
This is a TOCTOU violation and FilePayload.getInput already propagates
this. This commit allows external callers like jclouds-cli to
introspect on the exception type, returning a more friendly error
message in some situations.
Some providers (specifically HP Cloud and Google Cloud Storage) do not
properly support Expect: 100-continue headers. JDK7 is stricter in its
handling of the Expect header than JDK6 -- in particular, it expects
servers to properly respond to an expect header and times out only if a
prior timeout did not exist on the underlying HTTP connection. As a
result, JDK7 tests against these providers hang and fail.
This commit introduces a new filter -- appropriate called
StripExpectHeader -- that is controlled by the property
jclouds.strip-expect-header. The property defaults to false to preserve
existing behavior but allows applications to tweak Expect header
handling.
Tested by running HPCS live tests with JDK7 -- previously most of these
tests would fail with timeouts.
Closes JCLOUDS-181