Anonymous blob download returns 403 Forbidden

My C# program downloads a list of files from an Azure Storage blob using Azure.StorageServices.BlobService. But once it reaches a particular mono-2.0-bdwgc.dll file, I get a Response failed with status: 403 Forbidden response.

This file is the first inside of a subfolder (or whaterver the equivalent would be for a blob). If I add another file with a lower alphanumerical name (alpha.txt), now alpha.txt becomes the one that returns 403 Forbidden. Maybe something to do with subfolders? But some of the files downloaded before this one are under other folders.

All files can be accessed anonymously. In fact, I can even open the [...]/mono-2.0-bdwgc.dll or [...]/alpha.txt URIs in a browser and it downloads them with no issue. My resource paths always use forward slashes / as separators.

If explicitly try to download the file at the start of the program (before I start downloading the list of blobs), it also downloads it just fine. It only seems to complain if I try while downloading the whole list of blobs.

A barebones excerpt of my code:

StorageServiceClient client = StorageServiceClient.Create(STORAGE_ACCOUNT, blobKey);
blobService = client.GetBlobService();

...

for (int i = 0; i < blobsToDownload.Count; i++)
{
    await blobService.GetBlob(OnBlobReceived, blobsToDownload[i]);
}

private async void OnBlobReceived(IRestResponse<byte[]> response)
{
    if (response.IsError)
    {
        // This fails with 403 Forbidden
        throw new Exception($"{(int)response.StatusCode} {response.ErrorMessage} {response.Url}");
    }
    ...
}

I've noticed Microsoft recently changed the recommended x-ms-version header on MSDN to 2025-01-05, so I followed suit, but nothing changed.

Does anyone know why it would fail on this particular file on this particular occasion?

Update

I ended up removing the Azure.StorageServices.BlobService 12.23.0 package I was using and switched to the official Azure.Storage.Blobs (via NuGet for Unity) instead. After a quick implementation the problem seems to have gone away. I'm not sure what was causing it, as the same code was working less than a week ago, but at least it's fixed now.

Solution