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 a URI path for a blob in the listing results, the
Azure provider should re-encode any "bad" characters. Azure provider
also should not call trim() on the blob name, as that will remove any
leading or trailing space characters (which the provider supports). In
fact, the trim() call is only required because of the fact that when
parsing the XML document in the Azure tests, the white space between
the tags was also included in the values. Changing when the character
array is reset eliminates the need to do so.
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).
jclouds should not check if the string is encoded, but rather expect
that all strings would be encoded prior to transmission. As part of
that change, we must make sure that no code relies on such behavior
within jclouds. This commit adds a blobstore test to check encoding
pattern for blobs. It also removes the encoding check in the Strings2
class and the related test.
- Adding env_reset to the default configuration in /etc/sudoers
- Adding secure_path to the default configuration in /etc/sudoers
- secure_path value is
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Changed the LocalBlobStore to use FOLDER, as opposed to RELATIVE_PATH
when creating directories. Changed the delete keys strategy to treat
FOLDER blobs as regular blobs.
Azure does not allow arbitrary marker specification and the generic
testListContainerMarker test should not assume that the behavior is
possible. There is already a separate test for such scenario that is
skipped on Azure.
Get the faultCode and faultMessage to actually be parsed (though I'm
not sure they're ever used), add statusCode, statusMessage and
statusUpdateTime, and have AWSEC2TemplateOptions default to a sane 30
minute lifetime for spot instance requests, so they don't get orphaned
forever if the price is too low etc.
Timur Alperovich
Irmo Manie
Oliver Gondža
Yavor Yanchev
Nate Rosenblum
Zack Shoylev
Stuart Hendren
Andrew Gaul
Andrea Turli
Roman Coedo
Adrian Bravo
Arvind Nadendla
Ignasi Barrera
Andrew Bayer
Marcus Wanner
Ka-Hing Cheung