How to generate a non-SAS uri with custom Content-disposition in a public access container

Library name and version

Azure.Storage.Blobs 12.10.0

Query/Question

Lets say we have a public container in which we store files where each blob is a file. Because we don’t want to prompt the user every time they collide with another user’s filename then we store the stream of data under a generated GUID BlobName and not the actual filename. We however upload the file with a custom content-disposition so that the user will be able to recognize his or her file when downloading it.

var blobClient = _containerClient.GetBlobClient(blobName);
var blobUploadOptions = new BlobUploadOptions()
{
   HttpHeaders = new BlobHttpHeaders() { ContentDisposition = "attachment; filename=\"" + $"{blobName}.{extension}" + "\"; filename*=UTF-8''" + Uri.EscapeDataString($"{fileName}.{extension}") }
};

await blobClient.UploadAsync(stream, blobUploadOptions);

Since we don’t want our system to be the middle- man of downloading the file and then passing it on to the user then we want to construct a Uri with direct access to the blob in Azure blob storage and respects the custom content-disposition. This URI we then pass on to the user.

However, using the Uri property of the BlobClient won’t respect the custom content-disposition.

var blobClient = _containerClient.GetBlobClient(blobName);
return blobClient.Uri.ToString();

This is odd though because retrieving the custom content-disposition after it has been uploaded yields the correct result. As you can see in this picture the custom content-disposition is known to Azure blob storage but why is it not getting respected then?

Is there really not a way to generate a non-SAS uri that will respect the custom content-disposition?

We have had success generating SAS Uris respecting the custom content-disposition in the past but in this case where the container is of blob public access type then generating shared access tokens is not what we want.

Environment

.NET 6

[SatishBoddu-MSFT]

Hello @Brutiquzz Thanks for the query. We are routing this to the Service team to address the question.

[karol-gro]

Is there any update on this? Apparently, it’s a property of the blobs which has been there for years and no documentation mentions it (see https://stackoverflow.com/questions/54207583/azure-blob-storage-v2-does-not-deliver-content-disposition-header-any-more )

So, is this the result of some decision (if so, why is this and will this be documented? Or is it a defect in Azure Blob Storage (if so, when can we expect it to be fixed)?