Seems metadata needs to be prefixed with x-ms-meta- because of strip_prefix()

[benjaminch]

Bug Title

impl From<&Headers> for Metadata seems to require header keys to be prefixed with x-ms-meta-

Crate Name

azure_storage

Crate Version

0.21.0

Description

While trying to add metadata to a storage container using Headers, it seems that any header keys not starting with x-ms-meta- are not add populated into Metadata in impl From<&Headers> for Metadata.

Crate code:

impl From<&Headers> for Metadata {
    fn from(header_map: &Headers) -> Self {
        let mut metadata = Metadata::new();
        header_map.iter().for_each(|(name, value)| {
            let name = name.as_str();
            let value = value.as_str();
            if let Some(name) = name.strip_prefix("x-ms-meta-") {
                metadata.insert(name.to_owned(), value.to_owned());
            }
        });

        metadata
    }
}

reference:

azure-sdk-for-rust/sdk/core/azure_core/src/request_options/metadata.rs

Line 83 in 51f94b1

if let Some(name) = name.strip_prefix("x-ms-meta-") {

I am not sure whether it's bug or expected behavior? But strip_prefix("x-ms-meta-") returns None if input doesn't contain the prefix.
I would assume this code is just meant to strip this prefix if exists otherwise uses the key as is as it's done / possible via UI:

If this behavior is not expected, I would suggest to change impl From<&Headers> for Metadata implementation to this one:

impl From<&Headers> for Metadata {
    fn from(header_map: &Headers) -> Self {
        let mut metadata = Metadata::new();
        header_map.iter().for_each(|(name, value)| {
            let name = name.as_str();
            let value = value.as_str();
-            if let Some(name) = name.strip_prefix("x-ms-meta-") {
+            if let Some(name) = name.strip_prefix("x-ms-meta-").or_else(|| name) {
                metadata.insert(name.to_owned(), value.to_owned());
            }
        });

        metadata
    }
}

Happy to send a PR to fix this one if you consider it to be a bug.

Steps to Reproduce

Here's the code to reproduce the issue:

1. Execute the following code, creating a bucket with metadata not prefixed with "x-ms-meta-":

let client_builder = ClientBuilder::new("your-account", StorageCredentials::access_key("account".to_string(), "access-key".to_string()));

let client = client_builder.client();
let container_client = client
        .cloud_location(CloudLocation::Public {account: "your-account"})
        .container_client("a-test-bucket");

let mut metadata = HashMap::new();
metadata.insert(
    HeaderName::from("label-1"),
    HeaderValue::from("label-1-value"),
);
metadata.insert(
    HeaderName::from("label-2"),
    HeaderValue::from("label-2-value"),
);

container_client
    .create()
    .metadata(&Headers::from(metadata))
    .into_future().await?

2. Check the bucket metadata in UI, there will be nothing.
3. Execute the following code creating another bucket with metadata prefixed with "x-ms-meta-":

let client_builder = ClientBuilder::new("your-account", StorageCredentials::access_key("account".to_string(), "access-key".to_string()));

let client = client_builder.client();
let container_client = client
        .cloud_location(CloudLocation::Public {account: "your-account"})
        .container_client("a-test-bucket");

let mut metadata = HashMap::new();
metadata.insert(
    HeaderName::from("x-ms-meta-label-1"),
    HeaderValue::from("label-1-value"),
);
metadata.insert(
    HeaderName::from("x-ms-meta-label-2"),
    HeaderValue::from("label-2-value"),
);

container_client
    .create()
    .metadata(&Headers::from(metadata))
    .into_future().await?

4. Check the bucket metadata in UI, there will be metadata populated properly as label-1 and label-2.

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[vincenttran-msft]

Hi @benjaminch BenjaminCh, thanks for bringing this issue to our attention. We are currently underway with active development of the replacement Storage SDK crate, and this issue has since been resolved. With that being said, we dropped support for the legacy branch, and so no further updates will be released. Sorry for the inconvenience, but please be on the lookout for the updated Storage crate! Thanks!

[benjaminch]

Thanks @vincenttran-msft !
Just to be sure, how should I use the new crate instead of the legacy one? Can you point me toward the new crate?

Thanks