Reported by SDK devs at Rackspace. I would like to include these details in the Object Storage API 1.0 doc.
· Account metadata does not work the same way as some other metadata functions in object storage. In particular, a POST request will not reset all metadata to the specified values, but instead will update the metadata associated with the account in one of three ways:
o If the value for a key is not specified, it is removed if the key exists or otherwise ignored.
o If a value is specified for a key, and a value already exists for that key, then the value is updated.
o If a value is specified for a key, and the key is not already associated with the account, then a metadata item is added for the key and the given value assigned.
o If a metadata item is associated with an account, and it is not included in the POST request, then the key remains associated with the account and the value is unchanged.
o For the above rules, specifying the key X-Remove-Account-Meta-* with any value is equivalent to specifying X-Account-Meta-* with an empty value.
· I do not see any way to associate user-defined headers which do not start with X-Account-Meta- with an account.
· Metadata keys must be treated as case-insensitive at all times, and can only contain ASCII 7-bit characters which are not control characters (0-31), and not DEL, and not a separator character according to HTTP/1.1. In addition, Cloud Files does not support the underscore character, which it silently converts to a hyphen.
· The metadata values in Cloud Files do not follow HTTP/1.1 rules for character encodings. In particular, you will need to use a UTF-8 encoding to get a byte array for any string containing characters which do not fall into the 7-bit ASCII range (0-127). If you fail to follow this, then you’ll find that for ISO-8859-1 characters in the range 128-255, Cloud Files will return a 404 which is a direct violation of HTTP/1.1 §2.2.
Instead of "Cloud Files" throughout, be sure to use "Object Storage."