Editing Property Value causes value to become URL encoded

[bengavin]

Storage Explorer Version: 1.6.0
Platform/OS Version: Windows
Architecture: ia32
Regression From:

Steps to Reproduce:

1. Have blob with more than one metadata property
2. At least one property should have value that is NOT URL encoded (a:b,c:d)
3. Open blob properties dialog in Storage Explorer
4. Change a property value
5. Hit 'Save'

Expected Experience:

Metadata property value matches what was typed in the user interface when read by the Azure .NET libraries.

Actual Experience:

The property value is now URL encoded when retrieving from azure .NET libraries

[MRayermannMSFT]

Hi @bengavin , this is for a non-HNS enabled Storage account yes? If so, then this should be the correct behavior? From this doc:

Metadata name/value pairs may contain only ASCII characters. Metadata name/value pairs are valid HTTP headers, and so must adhere to all restrictions governing HTTP headers. It's recommended that you use URL encoding or Base64 encoding for names and values containing non-ASCII characters.

So before we set your metadata, we URL encode it. Are you saying the .NET libraries don't do this?

[MRayermannMSFT]

Oh, I think I understand now, we're encoding the entire string, but you only want it for the non-ASCII characters, yes? (and that is the recommendation: "URL encoding or Base64 encoding for names and values containing non-ASCII characters.")

[bengavin]

This seems to be a recent change. We have builds that push new BLOB images to Azure Storage, along with setting a number of Metadata Properties (via the x-ms-meta- header). Some of these properties are of the form:

x-ms-meta-Signatures: a:b,c:d

We then have a service running in Service Fabric that reads that blob metadata and extracts it, assuming that the returned information will be in the above format. We have been changing this data via Storage Explorer for quite some time, but with the latest revision, the 'Signatures' value is being changed to a%3Ab%2Cc%3Ad as it is read by our code. Looking at the data in Storage Explorer looks correct (as it must be decoding the value for display).

[bengavin]

So... I think yes to your proposed solution? :)

[MRayermannMSFT]

Ok, well we're shipping a hotfix next week for 1.6.0. I'll get the fix for this included in that. Until then, you can either use 1.5.0, or if you'd like, I can send you an early build of 1.6.1 to try out.

[bengavin]

Perfect, I can wait, I've just notified the team to avoid making updates with 1.6.0. I'll keep an eye out for 1.6.1! Thanks!

[MRayermannMSFT]

Ok! Sorry about the bug. I hope it hasn't caused you too much trouble. 😓

[MRayermannMSFT]

Fix merged into hotfix branch.