I have some code to add and delete entities from a table in Windows Azure using REST API's. If I add an entity with PartitionKey 'abcd' and RowKey 'efgh', and then delete it, it works fine. The relative URL for the delete operation is
devstoreaccount1/TableX(PartitionKey='abcd',RowKey='efgh')
This is used to create the authentication header, so the canonicalized resource for the signing string is
/devstoreaccount1/devstoreaccount1/TableX(PartitionKey='abcd',RowKey='efgh')
Everything is great and all works fine. Next, I insert another entity with partition key 'a b c d' and rowKey 'e f g h' (that is, added spaces). The entity inserts fine. when I try to delete it, I create the uri with spaces, and my request gets a response with error code 403. Basically the request did not authenticate. My next step to solve this issue is to change the values by calling HttpUtility.PathEncodeUrl(partitionKey) and the same for rowKey. So the canonicalized resource is now
/devstoreaccount1/devstoreaccount1/TableX(PartitionKey='a%20b%20c%20d',RowKey='e%20f%20g%20h')
When I make the request like this, I get a response with error code 404 (not found). This means, obviously that the authentication went through, but it seems as if internally the call handler forgot to convert the %20 back to spaces when searching for the entity keys.
OK, so after this long description, my 2 questions are: 1) What is the right way to encode the spaces so that it goes through authentication, and the entity is found for deletion? 2) In case one of the parameters includes a single quote, what is the right way to encode it in the string.
I prefer to use REST API's, so please don't respond by telling me to use the TableServiceContext class.
Thanks in advance for your help. One final note: The documentation on this topic in MSDN (http://msdn.microsoft.com/en-us/library/windowsazure/dd135727.aspx) is incorrect. It shows that the parameters should be sent in double quotes instead of single quotes. If you do this, the response is 403 (Forbidden access). It took me a while to figure that one out.