Get Blob Properties (HEAD Request) Failing 403, no details provided

Question

This on has me completely confused.

I have a reliable method for calculating signature values, it works for GET requests, etc. However when I issue the same process against my HEAD requests I get a 403, failed to authenticate the request, with no additional details.

To provide some background.

Here's an example of the string I'm signing for the HEAD request:

HEAD\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 03 Aug 2012 15:47:32 GMT\nx-ms-version:2009-09-19\n/king-kong/CDSplash.png

And here's an example of the request:

HEAD /king-kong/CDSplash.png HTTP/1.1
x-ms-date: Fri, 03 Aug 2012 15:47:32 GMT
x-ms-version: 2009-09-19
Authorization: SharedKey <REDACTED>:dE4T6wkuW/y0Gq60xBgMX19WzKhSrQMy3UrXFwiCb8k=

 And here's an example of the response:

HTTP/1.1 403 Server failed to authenticate the request. Make
sure the value of Authorization header is formed correctly including the signature.
Transfer-Encoding: chunked
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: e25d4b62-118a-4c16-95e8-c10b5d1555ec
Date: Fri, 03 Aug 2012 15:47:56 GMT
Host: <REDACTED>.blob.core.windows.net

Any suggestions would be great at this point. This application is 100% REST, with no access to the .NET apis. I'm guessing the "stringtosign" is inaccurate, but not sure, there's not a lot of good examples. I did test this same request with a 3rd party application, wireshark shows the identical (barring date) request go out, and a 200 response with data come back. I also checked, the clock is accurate.

Any ideas?

hz

Answer 1

I haven't done so for a while, but last time I looked the Storage Service responded to an error with the string it tried to sign that you could then compare with the string you signed.

You probably want to look at the definition of the canonicalized resource - specifically the location of the account.

-- Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

Answer 2

Nei's right. I think there's an issue with the way your Canonicalized Resource string is constructed. It is missing storage account name.

Answer 3

I haven't done so for a while, but last time I looked the Storage Service responded to an error with the string it tried to sign that you could then compare with the string you signed.

You probably want to look at the definition of the canonicalized resource - specifically the location of the account.

-- Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

Yes, that was it, /<ACCOUNT>/<CONTAINER> in the Canonicalized Resources.. Thanks guys, I was pulling my hair out on this one.

Answer 4

We're also using REST API exclusively in our products and one thing that helped us greatly is reading the response stream of the Web Exception. It has more details which will help you identify the root cause of the problem.

            try
            {
                //Your code here 
            }
            catch (WebException webEx)
            {
                string detailedErrorMessage = (new System.IO.StreamReader(webEx.Response.GetResponseStream(), true)).ReadToEnd()
            }

Thought I would share it with you.