Windows Azure tables Error solution when Partitionkey or Rowkey contains "%" characters

We find that services that apply Windows Azure tables will be affected when partitionkey or Rowkey contain a "%" character.

APIs affected by this include: Get entity, Merge entity, Update entity, Delete entity, insert or Merge entity, and API for insert or replace entity. If any of the above APIs are invoked with the Partitionkey or rowkey containing "%", the user will receive an error code 404 Not Found or bad request. In addition, when a user invokes an INSERT or merge entity and an INSERT or replace API, the request may succeed but the stored string may not be correct.

Note that the APIs for insert Entity, Entity Group transaction, and query datastore are unaffected because Partitionkey and rowkey are not part of their URL path.

Root cause

The Windows Azure table service repeatedly decodes the URL path part when processing the request, and the string containing "%" is incorrectly understood. Note the query string portion of the URL and the strings in the HTTP body section are not affected by this. Therefore, any other attribute filter in a query will not be affected-only partitionkey and Rowkey are affected.

Here's an example of how this problem occurs: an operation that inserts an entity and makes Partitionkey = "metric%25" and Rowkey = "Count" will succeed. Because Partitionkey, Rowkey and custom values are part of the request payload rather than the URL path part. Now, when you try to retrieve the existing entity, the Get Entity HTTP URL will look like the following:

Http://foo.table.core.windows.net/Metrics (partitionkey= ' metric%2525 ', rowkey= ' Count ')

However, due to the error of two decoding, Partitionkey will be translated to "metric%" on the server side, which is different from the original value. In this case, the 404 Not Found error will be returned.

Solution

If you have not yet used Partitionkey or rowkey with "%" in any entity, we recommend that you do the following two things:

avoid "%" in Partitionkey and Rowkey, or replace it with another word Furu "-". Consider applying URL-safe 64-bit encoding in Partitionkey and Rowkey.

Note: Do not repeat the Partitionkey and Rowkey value encoding as a workaround to avoid incompatible with the future release of Windows Azure tables containing server-side fixes.

If you have inserted an entity that contains "%" Partitionkey or Rowkey, we recommend the following solution:

for Get Entity: Use Entity Group transaction and use an internal get Entity command. (See the example in the following section) depending on the $filter variable when invoking the query Datastore API to attempt to retrieve a single entity. Although this method does not apply to users of the Windows Azure Storage client library or the WCF Data Services client library, it applies to users who have control over the transport protocol. For example, for the same entity mentioned in the "root cause" section above, the following query URL syntax can be considered:

Http://foo.table.core.windows.net/Metrics () $filter = (partitionkey%20eq%20 ' metric%2525 ')%20and%20 (rowkey%20eq% ' Count ')

for update Entity, Merge Entity, Delete Entity, insert or Merge Entity, and insert or replace Entity APIs, use Entity Group Transaction and the internal operations you want to perform. (See examples in the following section)

Solution Sample for Windows Storage client library

The

assumes that the user has inserted an entity containing Partitionkey = "metric%25" and Rowkey = "Count". The following code shows how to use the Windows Azure Storage client library to remove and update entities. This code applies the entity Group transaction solution mentioned earlier. Note that both the Get entity and update entity operations are performed as bulk operations.

  CREATE TABLE service context Tableservicecontext tableservicecontext = new tableservicecontext ( TableClient.BaseUri.ToString (),  tableclient.credentials); //  establish a single point of inquiry dataservicequery< metricentity> getentityquery =  (dataservicequery<metricentity>)        from entity in tableServiceContext.CreateQuery<MetricEntity> ( Customerstablename)      where entity. partitionkey ==  "Metric%25"  && entity. rowkey ==  "Count"      select entity; //  build Entity group  transaction and use internal get entity requests dataserviceresponse batchresponse =  Tableservicecontext.executebatch (getentityquery);             //  This is the only answer to bulk operations queryoperationresponse response =  (queryoperationresponse)   Batchresponse.first (); if  (REsponse. statuscode ==  (int)  httpstatuscode.ok) {    ienumerator queryresponse  = response. GetEnumerator ();     queryresponse.movenext ();    //  Read this individual entity     MetricEntity  singleEntity =  (metricentity) queryresponse.current;      //  Update Entity     singleEntity.MetricValue = 100;     tableservicecontext.updateobject (singleentity);         //  determine to store     tableservicecontext.savechanges using the bulk Operation option ( Savechangesoptions.batch);

Java Storage Client Solution code example

The same behavior occurs when a single entity operation is performed with the storage client Java library, which is related to the service. However, you can also apply entity Group transaction to solve this problem. The latest version of the library that can be used to implement the aforementioned solution can be found here.

//define bulk operation Tablebatchoperation batchoperation = new Tablebatchoperation (); Retrieve entity Batchoperation.retrieve ("metric%25", "Count", Metricentity.class); Submit an operation to the table service Tableclient.execute ("foo", batchoperation);

Long-term corrections

We will publish this fix as part of the next version update. We will update this post to reflect the version information that we are referring to.

We apologize for the inconvenience we have caused you!

Jean Ghanem