GetBlocKList error response doesn't contain UTF-8 BOM characters especially if blob is not found

[rambabu-yalla]

ISSUE : The GetBlockList API error response does not include UTF-8 BOM characters when the blob is not found — this behavior is specific to Azurite. In contrast, the actual Azure Blob Storage service includes BOM characters in its error responses.

Azureite Version: Tested with latest Azurite.

Error response snippet - This is the output of db command under windbg

• 3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 22 31 <?xml version="1
• 2e 30 22 20 65 6e 63 6f-64 69 6e 67 3d 22 55 54 .0" encoding="UT
• 46 2d 38 22 20 73 74 61-6e 64 61 6c 6f 6e 65 3d F-8" standalone=
• 22 79 65 73 22 3f 3e 0a-3c 45 72 72 6f 72 3e 0a "yes"?>..
• 20 20 3c 43 6f 64 65 3e-42 6c 6f 62 4e 6f 74 46 BlobNotF
• 6f 75 6e 64 3c 2f 43 6f-64 65 3e 0a 20 20 3c 4d ound. <M
• 65 73 73 61 67 65 3e 54-68 65 20 73 70 65 63 69 essage>The speci
• 66 69 65 64 20 62 6c 6f-62 20 64 6f 65 73 20 6e fied blob does n

Expected response:

• ef bb bf 3c 3f 78 6d 6c-20 76 65 72 73 69 6f 6e ...<?xml version

[blueww]

EmmaZhu-MSFT (@EmmaZhu)

Would you please help to look at this issue?

[jainakanksha-msft]

rambabu-yalla , Thank you for reporting this difference. We investigated the wire response and confirmed that Azure Blob Storage currently prefixes its XML responses with the UTF-8 BOM bytes EF BB BF, while Azurite does not.

However, **a BOM is optional for UTF-8 XML.
The Azure Storage REST documentation specifies an application/xml response encoded as UTF-8, but it does not document the BOM as required or provide a byte-level compatibility guarantee. XML with and without the BOM is valid. **

The official SDK behavior examined, as well as standard XML parsers, tolerates both representations. For example, the Azure Python SDK uses BOM-aware UTF-8 decoding: it removes the BOM when present but does not require one.

Could you please clarify the concrete failure caused by the BOM being absent?

What error or incorrect behavior occurs?
Does the client require byte-for-byte equality with Azure rather than XML-equivalent content?

This will help determine whether this is a functional client-compatibility problem or only an observed byte-level implementation difference. Without a client-visible failure, adding the BOM would be a fidelity enhancement rather than a fix required by the documented REST contract.