tracking: Azure Blob Delete does not honor If-None-Match wildcard semantics

[Xuanwo]

Summary

Azure Blob Storage's Delete Blob API accepts If-None-Match, but the live service does not apply the documented wildcard semantics when the value is *. It deletes an existing blob instead of rejecting the request.

This is an Azure Blob Storage service behavior discrepancy, not an OpenDAL bug. OpenDAL forwards the standard If-None-Match header unchanged.

Live service reproduction

Reproduced against the actual Azure Blob Storage service on 2026-08-27 using raw Shared Key REST requests, without OpenDAL or Azurite. The requests used x-ms-version: 2022-11-02.

Wildcard case:

1. Create a blob: 201 Created.
2. Delete it with If-None-Match: *: 202 Accepted.
3. Issue HEAD for the blob: 404 BlobNotFound.

The wildcard DELETE request ID was 91443d9d-701e-0018-5cfc-354f9c000000.

Control case using the blob's current ETag:

1. Create another blob: 201 Created.
2. Delete it with If-None-Match: <current-etag>: 412 ConditionNotMet.
3. Issue HEAD for the blob: 200 OK.

The control DELETE request ID was c1929a10-701e-006a-13fc-3548d3000000.

The control confirms that Azure evaluates If-None-Match for DELETE, but does not recognize * with its documented wildcard meaning.

Expected behavior

Azure documents that If-None-Match accepts *, and that the wildcard condition fails when the target resource exists. For a DELETE request, the service should return 412 Precondition Failed and leave the blob intact.

This also follows the HTTP semantics in RFC 9110 Section 13.1.2.

• Azure Blob Storage conditional headers
• Delete Blob
• RFC 9110 Section 13.1.2

OpenDAL impact

This issue tracks the external service limitation and any future Azure resolution. It does not propose an OpenDAL fix:

• OpenDAL already sends the caller-provided If-None-Match value as a standard HTTP header.
• Emulating the condition with HEAD followed by unconditional DELETE would introduce a race and would not provide atomic conditional-delete semantics.
• OpenDAL may document or test this provider limitation where relevant, but it should not claim that Azure honors wildcard conditional delete until the live service behavior changes.

Related to #8141 and #8157.

AI assisted with the live-service reproduction and drafting. The contributor directed the scope and conclusion.