Getting random exception while downloading blobs

Category: azure troubleshooting

Question

Ryder101 on Thu, 28 Apr 2011 15:22:16


Hello,

I've got a very strange problem with my azure application. I want my client to download two files from my azure blob every 30 minutes. While developing I dont want to wait 30 minutes, so I configured it to wait 10 seconds instead of 30 minutes.

The blob is private, but the client gets the URIs to the two blobs from the service, which is running in azure. The URI contains a shared access policy, so the clients can access the blob for 20 minutes.

Now the strange part: Accessing the blobs works maybe in 50% of all attempts. Here is a table of all attempts and the result:

True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:19:27Z&sr=b&si=readonly&sig=NpcVSfKqUXFJrCcip5KuOAK/CQeAAXNCOQZYUy8ITCQ=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:19:27Z&sr=b&si=readonly&sig=waJr5kZM0b583oUM01ANaAIkMwo1UQpg8MQ59esZxB8=
False	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:20:27Z&sr=b&si=readonly&sig=TC1s9LNP5Wd+ohvzm0dBHVu4J+sDX/zsyyMoTogoCVg=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:20:27Z&sr=b&si=readonly&sig=8GwNsioM1xDQPyqaS91i1ExneJmPK4AzT3vcYHriCMA=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:21:27Z&sr=b&si=readonly&sig=rbOTyuL2vZRrcSXx6/8M6khZsFx2Hx5gkqcpDcsvcWw=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:21:27Z&sr=b&si=readonly&sig=D0s2Gw5hILtxMVkEg46OUlyoP48p9rQMkMKOXZ/L4O8=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:22:27Z&sr=b&si=readonly&sig=TCDfhMpx130mqGz56FRXvnFfzranMOugRSj62Spj6JU=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:22:27Z&sr=b&si=readonly&sig=5DCwmaa9xR91Ew8TBtT8pDqXspkJq4ZNQA5se8/bykU=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:23:27Z&sr=b&si=readonly&sig=4nrUp1h9PcT8UYZyHs8p0Z9QBpctVkJdZ9wBXtw08ic=
False	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:23:27Z&sr=b&si=readonly&sig=8aRkFdGcuYRlVTCO+hsGd6fhio1rfjgo/sqwMcpbLWA=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:24:27Z&sr=b&si=readonly&sig=A9FQj9QGG6Q8wELYUQX2KOpdKQPVV78OEjBjrN2dWL8=
False	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:24:27Z&sr=b&si=readonly&sig=ROwMjPabNQ7vQyEE4K2hZg8UiB3w9oIVXsL5k7+SCaU=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:25:27Z&sr=b&si=readonly&sig=4ajMpPcNI50AKKPV7qroav9cV3xYsje9SxQ8hG2D5pg=
False	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:25:27Z&sr=b&si=readonly&sig=ZbTMNWuQyZ+wNvBc/TKVUGw3fJ/XFwinQtYy5VWYsWc=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:26:27Z&sr=b&si=readonly&sig=mTU73rxczJLHRs4SqyxR3TxVc8gFHeN7DlvXUdii4Mc=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:26:27Z&sr=b&si=readonly&sig=xfmTWEQLXEFoIlY/EmtvPnyBUOEA1iJUxblBX4TMlxI=
False	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:27:27Z&sr=b&si=readonly&sig=x+KFy+XtuG2mgfvfilAA/6bm2Y0GYqgCtS+Xrv2Wwms=
False	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:27:27Z&sr=b&si=readonly&sig=qlyjIyMi8LjZ6ZgaMjGSux4Auwn+wwH+HziIISjrVYA=
True	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:28:27Z&sr=b&si=readonly&sig=5JhQH1QIooeHX3sKWEl3X9kA8rbiadRQOpEaUhpPpcw=
False	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:28:27Z&sr=b&si=readonly&sig=63r+bZ4qwexCsLCss1gjpSH3fsXHTahLTBnQXwEyoQc=
False	https://myaccount.blob.core.windows.net/filepackets/900a1406-9710-4062-a378-3ff468b01293?se=2011-04-28T15:30:27Z&sr=b&si=readonly&sig=czzP+qETFwawYJOaCfROaWnzcZAtQCW4weF2VH0ARDQ=
True	https://myaccount.blob.core.windows.net/filepackets/5a34ed0e-7784-47e8-b9cd-80e04aec4bf5?se=2011-04-28T15:30:27Z&sr=b&si=readonly&sig=ICYhJVUcEoNThMVE0kx6KzqFvLJvnzCYsGyD7AfsHo0=

You see: sometimes, one download works, sometimes both download work, and sometimes no download works.

Accessing a blob file which did not work, via browser, leads to the following message:

 

<Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:029de990-408e-4103-8734-bc96beaaafb7
Time:2011-04-28T15:20:28.5848111Z</Message><AuthenticationErrorDetail>Signature fields not well formed.</AuthenticationErrorDetail></Error>

Do you have an idea? Thank you very much!

Replies

Ryder101 on Thu, 28 Apr 2011 18:41:51


Solved it!

Thr blob uri is generated on server side. The blob uri is a string. This string gets converted to an URI object. Now this URI object is send to the client via WCF.

On the server side the URI object contains in the AbasoluteUri property the blob uri with all special signs. The OriginalString property contains the blob uri with escaped special signs.

On the client side all special signs are not escaped! The escaped special signs get lost while (de-)serializing oder sending the URI-object via WCF.

And the message that "signature fields are not well formed" appears always when the blob URI a "+" sign contains.

Is this a bug in WCF?

E_L_S on Thu, 19 Jan 2012 15:11:07


I've been experiencing this issue myself and it's to do with URL encoding.

When you use their SDK to calculate the signature string (sig parameter on the URL), Microsoft give you the Base 64 signature string "as is".

But to be able to put it on a URL (that can do an HTTP GET) you need to encode the + / = characters otherwise the Microsoft machine doesn't interpret them literally.

In the Base64 signature string text:

'+' needs changing to '%2B'

 '/' needs changing to '%2F

'=' needs changing to  '%3D'

See "Example GET Operation" in http://msdn.microsoft.com/en-us/library/windowsazure/ee395415.aspx