On Windows, we need to avoid trailing spaces, as the test fails to
create the required blob. Specifically, we should not test blobs named
" " and "%20 ".
When constructing the expected HTTP requests in STS tests, STS API
should not pre-encode the strings. The form parameters are already
encoded and are otherwise encoded twice.
When constructing the query path, S3 does not properly handle encoded
paths. For example, if a blob named %20 is to be placed into the blob
store, S3 would end up placing blob named " " (what %20 represents).
This occurs because the S3 provider examines the URI's path portion
(which is presented in a decoded fasion to the caller). After
examining the path, it is not encoded again. Instead, we should call
getRawPath() to avoid this issue.
There are two issues on the decoding path:
1. Given a blob named " ", S3 API will throw a RuntimeException due to
a NULL check -- the key that it uses is NULL to represent the XML
content " " corresponding to the blob name.
2. Given a blob named "%20 ", S3 API will generate a URI for a blob
named "%20%20", which is also incorrect. The correct URI would be
"%2520%20" (escaping the first "%" and " " characters).
The first issue is due to the currentOrNull() helper, which calls
trim() on the string and then compares the string to an empty string.
This means that a blob named " " will be parsed as "" and then
converted to NULL as the result of that method. Passing "null" as the
key then fails in a number of places (notably, appendPath()).
The second issue is due to the appendPath() method in the jclouds Uris
class. The issue here is that appendPath() calls urlDecode() and
passes the result to path(). The path() method, in turn, also calls
urlDecode(). After these transformations, a properly encoded blob of
the form %2520%20 turns into "%20 " and then " " (two spaces). After
these transformations the path is encoded again, resulting in "%20%20"
(which is wrong).
deprecated hardware types in EC2 are flagged using this, according to latest AWS advice,
to fix situations where deprecated hardware types would be chosen when a non-deprecated alternative exists.
we also deprecate T2 because it requires a VPC.
also fixes semantics of ImagesToRegionAndIdMap to match the logic used in the TemplateBuilderImpl;
RegionAndName should contain the ID not the ProviderID. this is only really used in tests so no external impact.
(previously the cache only worked if provider ID matched the non-location segment of the image ID.)
however this does now assert that image id's are in the right format for AWS, as suggested by @nacx.
Move the prefix and delimiter tests from BaseContainerLiveTest to
BaseContainerIntegrationTest, as that class is subclassed in
Filesystem integration tests. This will make sure the file system blob
store will not regress.
The ListContainerTest is updated to _not_ use a file separator
character, as that leads to a possible creation of directories.
Instead, "-" is used as the delimiter for the delimiter option tests.
The patch adds the delimiter support in the openstack-swift API. As
part of the change, the subdirectory support in results is introduced.
This occurs when a prefix and delimiter options are set and there are
subdirectories present in the listing (i.e. multiple objects under the
same prefix/delimiter). In this case, Swift will return a list of
"subdir" objects (similar to CommonPrefixes in S3), which need to be
treated differently.
The patch adds delimiter option support in the generic blob store
interface. A live integration test is added to verify that jclouds
correctly lists objects separated by a delimiter.
Openstack Swift ContainerApiLiveTest testListWithOptions assumes that
there are no other containers and that ContainerApiLiveTest container
will _always_ be the first container.
The patch changes the behavior of the test to instead pull out the
container from the returned list.
There is no notion of marker blobs in the file system blob store,
which means that when listing results after issuing the
"createDirectory" request, the marker blob will not be in the result
set.