Windows Azure ストレージの既知の問題
このポストは、11 月 24 日に Windows Azure Storage Team が投稿した Windows Azure Storage Known Issues (November 2013) の翻訳です。
マイクロソフトは、CORS や JSON などの主要機能のリリースに対する準備として製品の更新を進めていますが、これに不具合が含まれていることがわかりました。この不具合についてご報告をいただいたため、今後の修正プログラムで対応する予定です。修正プログラムが公開され次第、当ブログでお知らせいたします。
Windows Azure BLOB 、テーブル、キューの Shared Access Signature (SAS)
マイクロソフトは、2012-02-12 バージョンの SAS で HTTP ステータス コード 400 (無効な要求) が返されるという問題の報告をユーザーからいただきました。調査の結果、この問題は、コンテナーの前の “//” という文字列をサービスが解釈する方法が変更されたことによるものであると判明しました。
例: https://myaccount.blob.core.windows.net // container/blob?sv=2012-02-12&si=sasid&sx=xxxx
2012-02-12、またはそれ以前のバージョンで SAS の要求を受け取った場合、古いバージョンのサービスでは ‘//’ を ‘/’ として解釈し、これによって正常に動作していました。しかし、今回のサービスの更新では、上記の URI を受け取った場合にコンテナー名が null であると判断され、これは無効であるため、ステータス コード 400 (無効な要求) が返されるようになりました。現在、2012-02-12 バージョンの SAS で以前のように ‘//’ を ‘/’ と解釈するように戻す作業を実施しています。これに伴い、皆様には、URI のコンテナー名部分の冒頭に ‘//’ を付けないようにしていただくことをお願いいたします。
Windows Azure テーブル
既知の問題が 2 つ存在します。マイクロソフトでは、サービス側およびクライアント ライブラリの一部に対して修正プログラムを適用する予定です。この問題の詳細は、以下のとおりです。
1. クライアントが DataServiceContext.ResolveName (英語) を定義するときに type の名前を <アカウント名>.<テーブル名> の形以外で指定すると、CUD の処理でステータス コード 400 (無効な要求) が返されます。これは、新しい更新では、“term” を含む ATOM の “Category” 要素が省略されているか、<アカウント名>.<テーブル名> と同一である必要があるためです。以前のバージョンのサービスでは、送信された type 名はすべて無視されていました。この問題について、送信される名前を再度無視するように修正することで解決する予定ですが、修正が適用されるまでの間は、クライアント アプリケーションで下記の回避方法を検討していただく必要があります。ResolveName は Azure テーブルでは必須ではなく、クライアント アプリケーションはこれを削除して、OData が “category” 要素を送信しないようにすることができます。
下記のコード スニペットは、サービス側で不具合が発生する要求を生成する例です。
CloudTableClient cloudTableClient = storageAccount.CreateCloudTableClient();
TableServiceContext tableServiceContext = cloudTableClient.GetDataServiceContext();
tableServiceContext.ResolveName = delegate(Type entityType)
{
// この部分により、クラス名が category 要素の term の値として送信されます。これが、サービスが無効な要求を返す原因となります。
return entityType.FullName;
};
SimpleEntity entity = new SimpleEntity("somePK", "someRK");
tableServiceContext.AddObject("sometable", entity);
tableServiceContext.SaveChanges();
クライアント側でこの問題を回避するには、強調表示されている “tableServiceContext.ResolveName” デリゲートを削除してください。
マイクロソフトは、この問題をご報告いただき、調査に協力してくださった restaurant.com (英語) に感謝いたします。
2. 今回の更新の一部としてサーバー側で使用されている新しい .NET WCF Data Services ライブラリは、$filter クエリの一部として実行される空の “cast” を、ステータス コード 400 (無効な要求) を発行して拒否します。以前の .NET Framework ライブラリでは、これが拒否されることはありませんでした。IQueryable の実装 (詳細についてはこちらの記事 (英語) を参照) により cast 演算子が特定のシナリオで送信されるため、Windows Azure ストレージ クライアント ライブラリ 2.1 は上記の影響を受けます。
.NET の DataServiceContext は cast 演算子を送信しませんが、マイクロソフトはこの動作に適合するようにクライアント ライブラリの修正を進めています。修正プログラムは数週間以内にリリースできる予定です。その間、ユーザーの皆様には、下記の回避策を実施していただきますようお願いいたします。
このクライアント ライブラリの問題は、可算型を ITableEntity インターフェイスに固定せず、インスタンス化する必要のある型に対し正確に固定することで回避できます。
下記のコードを見ると、この動作がおわかりいただけるかと思います。
static IEnumerable<T> GetEntities<T>(CloudTable table) where T : ITableEntity, new()
{
IQueryable<T> query = table.CreateQuery<T>().Where(x => x.PartitionKey == "mypk");
return query.ToList();
}
ストレージ クライアント ライブラリ 2.1 の IQueryable インターフェイスでこのコードを実行すると、今回の新しいサービスではステータス コード 400 (無効な要求) により拒否される下記の URI のようなクエリが送信されます。
https://myaccount.table.core.windows.net/invalidfiltertable?$filter=**cast%28%27%27%29%** 2FPartitionKey%20eq%20%27mypk%27&timeout=90 HTTP/1.1
これを回避するには、上記のコードを下記のクエリに書き換えて、cast 演算子が送信されないようにします。
IQueryable<SimpleEntity> query = table.CreateQuery<SimpleEntity>().Where(x => x.PartitionKey == "mypk");
return query.ToList();
この要求の URI は次のようになり、サービスが受理します。
マイクロソフトは、不具合の発生についてお詫び申し上げると共に、これを解決する修正プログラムの作成に取り組んでいます。ご理解のほどどうぞよろしくお願いいたします。
Windows Azure ストレージ チーム
Comments
- Anonymous
December 18, 2013
1234567890-^qwertyuiop@[ asdfghjkl;:]zxcvbnm,./