Azure-sdk-for-go: SetBlobMetadata may change the case of the existing meta data name

[yuwaMSFT2]

In C# client, we put a metadata "name=key".
In Go, we could query the metadata "name=key". Now if we can SetBlobMetadata with the same metadata, the metadata on the blob will be changed to "Name=key".

This is because in client.exec, we call req.Header.Add, which will convert the key to MIMEHeader which will make the first chacater of a word uppercase.

For Storage REST API, the metadata is set through header:
x-ms-meta-name

With the canonization, the header becomes:
X-Ms-Meta-Name

Server will change the metadata name to "Name" now.

Now if C# client tries to get the metadata with "name", it gets nothing.

Go sdk should not change the case of the name (although I think C# sdk can also do some improvement here).

[yuwaMSFT2]

The fix would be to avoid using MIMEHeader convention for these metadata headers.
Instead of calling req.Header.Add, can call req.Header["name"] = "key" directly.

[yuwaMSFT2]

@marstr @DavidObando @SajayAntony @mcardosos @sivagms

[marstr]

Howdy @yuwaMSFT2, this is a really interesting bug. We've decided your fix is correct, and I'll try to get out a PR out here quickly to fix it.

The relevant Azure documentation is here: https://docs.microsoft.com/en-us/rest/api/storageservices/setting-and-retrieving-properties-and-metadata-for-blob-resources which says:

Names are case-insensitive. Note that metadata names preserve the case with which they were created, but are case-insensitive when set or read.

It's less easy to see here, but as you point out the Go Standard Library is munging the case as the user sets it in the Header type.

As you point out, the service handles this fine, but apparently both clients need to be better citizens about interacting with this service. (As an aside, given that HTTP Headers are supposed to be case-insensitive, I think the behavior the service has chosen is kinda silly.)

[sajayantony]

@marstr Does this mean storage's behavior should change?

[marstr]

Yep! working on the PR now

[marstr]

The PR to address this is #646