Been fighting with the problem for a month now. Have Drupal 9 set up on Azure App service with docker images running php8 (base image drupal:9.1.7-php8.0-apache) I have found out that there are two ways to have the "sites/default/files" public files directory served in azure:
Symlink "sites/default/files" folder to "/home/files" folder and set WEBSITES_ENABLE_APP_SERVICE_STORAGE to true in application settings.
Mount Azure file share directly on top of "sites/default/files" folder using Path mappings (currently in preview).
Both options works, my files are uploaded successfully and I can see them in the storages. Drupal also sees those files, BUT every time I try to access any of the uploaded files, I get 500 error with the only error being Failed to forward request to application. Encountered a System.Net.Http.HttpRequestException exception after 119.915ms with message: Received an invalid status line: 'anges: bytes'.. Check application logs to verify the application is properly handling HTTP traffic.
If I delete the uploaded file, the app reacts and shows that file not found instead.
It seems that the azure only serves text files normally, because css/js/txt files are delivered just fine, only images. Lets say I upload sample.png image, it shows 500 error. If i change that image to sample.txt, it shows not even the text but the whole image without any problem, if i download that sample.txt and change it to sample.png the image is displayed normally in windows. So I assume this is only images problem (EDIT: Tried .zip and .docx, getting error 500 aswell).
If I disable persistent storage (any of the options mentioned above), the files are uploaded correctly, no errors are shown, but the problem is that every time the app is restarted or deployed, the files are gone.
Drupal has no errors in its log. Apache logs have no more useful info (GET seems to be ok and returns 200). Have tried messing with apache.conf, with php.ini, with both .htaccess files allowing all kinds of nasty things, but still have no clue. Had multiple colleagues look into this and nothing seems to work.