How can I construct canonical resource for Azure Storage Table Set Table Service Properties endpoint?

Question

Azure exposes an endpoint to set table service properties . This endpoint expects client to pass Authorization header and that could be formatted as SharedKeyLite <account-name>:<signature> for Table services as explained here . signature is the sha256 encoded form of <date>\\n<canonical-resource> for which canonical resource construction follows the rules:

1. Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.
2. Append the resource's encoded URI path. If the request URI addresses a component of the resource, append the appropriate query string. The query string should include the question mark and the comp parameter (for example, ?comp=metadata). No other parameters should be included on the query string.

according to Authentication documentation .

I am able to authenticate for query tables or entity operations . However, I am consistently failing to authenticate for set table service properties endpoint. I construct canonical resource by starting with "/<account-name>" according to rule 1 and then I append another "/" without any query string, because I believe request URI (which is https://<account-name>.table.core.windows.net/?restype=service&comp=properties ) is not addressing a component according to rule 2 . That makes canonical resource "/<account-name>/" .

Is there anybody managed to authenticate for this endpoint at all? If so how?

NOTE 1: I tried otherwise (appended query string too and that made the canonical resource "/<account-name>/?comp=properties" ), but failed again.

NOTE 2: Rule 2 asks to append encoded URI path, but that is not really the case.

Answer 1

I was able to partially resolve the issue. The problem is Azure storage emulator behaves different than the actual storage service. Set Table Service Properties endpoint is not authenticating the request on the emulator whereas it goes through fine on the service itself. Other requests against table (read, create, delete) and entities (create, read, update and delete) are behaving same on emulator and service.

The canonical resource is formatted as "/<account-name>/?comp=properties" . Content type makes no difference in authentication as expected.