mirror of https://github.com/apache/jclouds.git
a0b95ea7a3
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). |
||
|---|---|---|
| .. | ||
| src | ||
| pom.xml | ||