blueww
commented
1 month ago @viswanr
Thanks for raising this issue!
Do you mean you upload/download same blob with different Uri, upload with not encoded uri, download with encoded uri? If you could share the Azurite debug log, we can be more clear on which Uri Azurite receive.
If this is the case, and if the different Uris both work on product Azure, this issue looks an undocumented behavior of product Azure. It will take time to add this support the Azurite, since if there are no clear doc for this behavior, we need first contact server team and get a clear picture of how this feature works, include all cornet cases. It might take a long time. Besides that, we also has other feature requests on hand, we will priority this item together with other feature items, and this item might won't be our highest priority in the recent future.
As you said , this issue only occur on Java app but not .net and js app, so this looks more like a Java app issue, since it upload/download same blob with different Uri. I see you have already opened an issue for Java. It would be better if Java app could fix this issue.
viswanr
Which service(blob, file, queue, table) does this issue concern?
Blob
Which version of the Azurite was used?
3.29.0
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
DockerHub/MCR
What's the Node.js version?
18
What problem was encountered?
We are running an integration test written in Typescript using Docker, where we have a container with our Java Function app an d it calls to into Azurite, the official storage emulator from Azure. The Java Azure Function is running in Docker along with Azurite within the same network.
The PUT request to upload the file to Azurite is as follows, which is successful: "PUT /devstoreaccount1/tdigests/hourlyDigests/v2/EMEA/t2_1/ChatSwitch/eyJBcHBJbmZvX0NsaWVudFR5cGUiOiJ3ZWIiLCJBcHBJbmZvX0Vudmlyb25tZW50IjoicHJvZCIsIkFwcEluZm9fRXhwZXJpZW5jZU5hbWUiOiJyZWFjdC13ZWItY2xpZW50IiwiRGVyaXZlZF9Vc2VySW5mb19FZHVUeXBlIjoiRURVIiwiY29udGV4dFR5cGUiOiJ0Ml8xIiwiZXZlbnROYW1lIjoiY2hhdF9zd2l0Y2giLCJncm91cGluZ05hbWUiOiJBcHBJbmZvX0NsaWVudFR5cGUiLCJtZXRyaWNLaW5kIjoibGF0ZW5jeSJ9/2024-04-07/21/tdigests.json HTTP/1.1" 201
Now, when we look at the URL that the Java app is using for the GET request,
"GET /devstoreaccount1/tdigests/hourlyDigests%2Fv2%2FROW%2Ft2_1%2FChatSwitch%2FeyJBcHBJbmZvX0NsaWVudFR5cGUiOiJ3ZWIiLCJBcHBJbmZvX0Vudmlyb25tZW50IjoicHJvZCIsIkFwcEluZm9fRXhwZXJpZW5jZU5hbWUiOiJyZWFjdC13ZWItY2xpZW50IiwiRGVyaXZlZF9Vc2VySW5mb19FZHVUeXBlIjoiRURVIiwiY29udGV4dFR5cGUiOiJ0Ml8xIiwiZXZlbnROYW1lIjoiY2hhdF9zd2l0Y2giLCJncm91cGluZ05hbWUiOiJTY2VuYXJpb19TdGF0dXMiLCJtZXRyaWNLaW5kIjoibGF0ZW5jeSJ9%2F2024-04-07%2F23%2Ftdigests.json HTTP/1.1" 404
As you can see, the slashes in the path are being encoded. Consequently, this is causing the following 404 issue where it cannot find the blob (since the path is wrong because of the encoding). The download path is not encoded before the GET request is sent, but it seems like it is getting encoded during transit to Azurite.
This behavior seems to happen only in the Java SDK. We have similar setups with .NET and Nodejs Function apps, and they work well with Azurite. https://github.com/Azure/azure-sdk-for-net/pull/30271
Here is an issue we filed on the Java SDK - https://github.com/Azure/azure-sdk-for-java/issues/40370
Since the actual Azure Blob Storage service in production treats slashes and %2F the same, Azurite should emulate the same.
Steps to reproduce the issue?
If possible, please provide the debug log using the -d parameter, replacing \<pathtodebuglog> with an appropriate path for your OS, or review the instructions for docker containers:
Please be sure to remove any PII or sensitive information before sharing!
The debug log will log raw request headers and bodies, so that we can replay these against Azurite using REST and create tests to validate resolution.
Have you found a mitigation/solution?