- Issue created by @Driskell
- 🇭🇺Hungary tikaszvince
I think this is already fixed in 🐛 When AssetControllerBase delivers existing file should add content-type Fixed
- Status changed to Closed: duplicate
11 months ago 1:52pm 24 July 2023
When an asset is generated multiple times and a second request to AssetController sees that the file already exists and delivers it - the BinaryFileResponse does not specify a Content-Type.
Since D10 it seems there is no registered guesser like in D9 so it uses file_info or similar. This is notoriously inaccurate.
For example, the below bundle file is detected as assembler source text (text/x-asm) and multiple other of my bundles are detected as text/plain. This prevents the browser from loading them.
css_po4KdqlRZWF8CfE0QBHXRKXwhj22MhbNT8WiGLDtx9w.css: assembler source text, ASCII text, with very long lines (24366)
Mitigation is that this only happens in a race during initial generation - subsequent requests are directly handled by static file serving of the web server and do not go via PHP and so use a more reliable static content type MIME table in most cases. But this is fairly frustrating as it can happen during deployments where JS changes occur, and can raise false alarms of a deployment issue.
Turn off static file serving in Apache or Nginx and push asset requests always to PHP.
This will simulate requests going to PHP for a JS/CSS aggregate that already exists because another parallel request finished processing it that same moment.
Add content-type header to BinaryFileResponse
-
-
-
-
-
I think this is already fixed in 🐛 When AssetControllerBase delivers existing file should add content-type Fixed