2016-07-22 165 views
0

我們的應用程序需要上傳大小爲0的blob。 我們使用cURL來調用Azure存儲REST API。 雖然與大小上傳它與HTTP錯誤代碼[400]Azure blob存儲:無法上傳大小爲0的blob

失敗以下錯誤消息,它返回


<?xml version="1.0" encoding="utf-8"?> 
    <Error> 
      <Code>InvalidHeaderValue</Code> 
      <Message> 
        The value for one of the HTTP headers 
        is not in the correct format. 
        RequestId:2b1ec18b-0001-007d-7811-e40725000000 
        Time:2016-07-22T12:07:28.5435467Z 
      </Message> 
      <HeaderName>Content-Length</HeaderName> 
      <HeaderValue>-1</HeaderValue> 
      </Error> 

通過Wireshark的,我們保證,內容長度的值頭部被適當地發送。

以下是從Wireshark的捕獲的頭


PUT /test/DC70439C-5004-11E6-B4B2-91D87435845D HTTP/1.1 
Host: mytest.blob.core.windows.net 
Accept: */* 
Transfer-Encoding: chunked 
x-ms-blob-type:BlockBlob 
x-ms-version:2015-02-21 
Content-Length:0 
x-ms-date:Fri, 22 Jul 2016 12:07:28 GMT 
Authorization:SharedKey kanchan:HQQ7a47TPQtEhL0ek6rim64ZKC8NRubgKuq+4Os+Aoo= 
Expect: 100-continue 

你能幫助普萊舍弄清楚爲什麼Content-Length頭值被設置爲-1?

感謝和問候, 拉胡爾·奈克

+0

以下是字符串簽署用於生成授權報頭 PUT X-MS-團塊型:BlockBlob X-MS-日期: 2016年7月22日星期五12:07:28 GMT x-ms-version:2015-02-21 /test/test/DC70439C-5004-11E 6 B4B2-91D87435845D 由於我們使用的版本2015年2月21日,我們確保存在stringToSign不加Content-Length頭,如果它的長度爲0 –

回答

0

我沒有重現您的問題。以下是我使用cURL將文件上傳到Azure blob存儲的測試代碼。它適用於我,我可以上傳大小爲0的文件(將文件內容設置爲「」)。希望這可以給你一些提示。

storage_account="<account name>" 
container_name="<container name>" 
access_key="<account key>" 
content="<file content>" 
len=${#content} 
blobname="<blob name>" 
blob_store_url="blob.core.windows.net" 
authorization="SharedKey" 
request_method="PUT" 
request_date=$(TZ=GMT date "+%a, %d %h %Y %H:%M:%S %Z") 
storage_service_version="2011-08-18" 
# HTTP Request headers 
x_ms_date_h="x-ms-date:$request_date" 
x_ms_version_h="x-ms-version:$storage_service_version" 
# Build the signature string 
canonicalized_headers="x-ms-blob-type:BlockBlob\n${x_ms_date_h}\n${x_ms_version_h}" 
canonicalized_resource="/${storage_account}/${container_name}/${blobname}" 
string_to_sign="${request_method}\n\n\n${len}\n\napplication/x-www-form-urlencoded\n\n\n\n\n\n\n${canonicalized_headers}\n${canonicalized_resource}" 
# Decode the Base64 encoded access key, convert to Hex. 
decoded_hex_key="$(echo -n $access_key | base64 -d -w0 | xxd -p -c256)" 
signature=$(printf "$string_to_sign" | openssl dgst -sha256 -mac HMAC -macopt "hexkey:$decoded_hex_key" -binary | base64 -w0) 
authorization_header="Authorization: $authorization $storage_account:$signature" 


curl \ 
    -X PUT \ 
    -H "$x_ms_date_h" \ 
    -H "$x_ms_version_h" \ 
    -H "Content-Type: application/x-www-form-urlencoded" \ 
    -H "$authorization_header" \ 
    -H "x-ms-blob-type:BlockBlob" \ 
    -d ${content} "https://${storage_account}.${blob_store_url}/${container_name}/${blobname}" 
0

看來「坎」不匹配「mytest的」。我們可以在此鏈接中找到此信息:https://msdn.microsoft.com/en-us/library/azure/dd179428.aspx

Authorization:SharedKey kanchan:HQQ7a47TPQtEhL0ek6rim64ZKC8NRubgKuq+4Os+Aoo= 

從我們可以發現,該文件「坎」是帳戶名稱。但是,主機信息「mytest.blob.core.windows.net」顯示「mytest」。也許這是問題。

+0

對不起其我的壞。 Kanchan是帳戶名稱。在發佈這個問題之前,我嘗試用mytest替換kancahn,但是這個錯過了。 –