2016-07-22 3 views
0

Наше приложение требует загрузки блоба с размером 0. Мы используем cURL для вызова API REST Azure. При загрузке с размером его неудачу с HTTP кодом ошибки [400]Хранилище Azure blob: невозможно загрузить блоб размером 0

следующее сообщение об ошибке вернулся


<?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 

Вы можете PLese помощь, чтобы выяснить, почему значение заголовка Content-Length было установлено как -1?

Спасибо и уважение, Рахул Найк

+0

Ниже приводится строка знак используется для генерации заголовок авторизации PUT X-MS-блоб-тип: BlockBlob X-MS-дата: Пт, 22 июл 2016 12:07:28 GMT x-ms-версия: 2015-02-21 /test/test/DC70439C-5004-11E 6-B4B2-91D87435845D Поскольку мы используем версию 2015-02-21, мы гарантировали, что в stringToSign не добавлен заголовок длины контента, если его длина равна 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

Извините, это мое «плохое». Канчан - это имя учетной записи. Прежде чем отправлять этот вопрос, я попытался заменить kancahn на mytest, но этот пропущен. –