BlobClient::GetProperties()/Download() throw std::out_of_range when a 2xx response omits x-ms-blob-type

[clee704]

Describe the bug

BlobClient::GetProperties() and BlobClient::Download() throw std::out_of_range (from std::map::at) — not an Azure::Storage::StorageException / Azure::Core::RequestFailedException — when the service returns a successful (2xx) response that does not include the x-ms-blob-type response header.

The Get Blob and Get Blob Properties readers deserialize the header unconditionally:

response.BlobType = Models::BlobType(pRawResponse->GetHeaders().at("x-ms-blob-type"));

x-ms-blob-type is generated as required (a bare .at(...)), whereas every optional header in the same reader — including ETag and Last-Modified — is read behind a GetHeaders().count(...) != 0 guard. When a 2xx response omits the header, std::map::at throws std::out_of_range, which a caller's catch (const StorageException&) does not catch, and which aborts an otherwise-usable read (size, ETag, content range are all present; the read path frequently does not use BlobType).

Exception or Stack Trace

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Thrown from the BlobClient::GetProperties / BlobClient::Download response deserialization in sdk/storage/azure-storage-blobs/src/rest_client.cpp.

To Reproduce

Call BlobClient::GetProperties() or BlobClient::Download() against any endpoint that returns HTTP 200 without the x-ms-blob-type header. A concrete case: a BlobClient targeting the OneLake / ADLS Gen2 *.dfs.fabric.microsoft.com (DFS) endpoint — it answers Blob Get Blob Properties / Get Blob with 200 but omits x-ms-blob-type (the blob-protocol response is served from the parallel *.blob.fabric.microsoft.com endpoint).

Code Snippet

// blobClient targets a host that returns 200 without x-ms-blob-type
auto blobClient = Azure::Storage::Blobs::BlobClient(url, credential);
auto props = blobClient.GetProperties();   // throws std::out_of_range

Expected behavior

The call should not throw std::out_of_range. A missing x-ms-blob-type on an otherwise-successful response should be tolerated — e.g. BlobType left as a default Models::BlobType — consistent with how ETag / Last-Modified are already handled on the same responses. (If a missing required header is to be treated as an error, it should at least surface as a typed exception, not a raw std::out_of_range.)

Setup (please complete the following information):

• OS: any (platform-independent response-parsing path)
• Version of the Library used: azure-storage-blobs, reproduced on current main (also present in released 12.x)

Additional context

Mirrors the existing "striped blob" compatibility fix for x-ms-blob-sequence-number (PR #3932, commit 0e00a3a), which marked a similarly-required header optional via an x-nullable swagger directive plus the matching generated-file guard. A PR taking the same approach for x-ms-blob-type on Blob_GetProperties and Blob_Download follows.

Information Checklist

• Bug Description Added
• Repro Steps Added
• Setup information Added

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Jinming-Hu @microzchang @vinjiang.

[Jinming-Hu]

It is not our goal to be compatible with OneLake. But I guess it doens't harm to change this one header from required to optional. I'll need to update codeGen to make this happen.