Feature #91493


Add documentary and improve warnings for "Server Response on static files" check

Added by Hannes Strangmeier about 4 years ago. Updated 11 months ago.

Should have
Target version:
Start date:
Due date:
2020-05-11 (over 4 years late)
% Done:


Estimated time:
PHP Version:
Sprint Focus:


Hey folks,

when TYPO3 is not capable of performing a HTTP-Request on itself - e.g. when there's a basic-auth-protection on the site - the "Server Response on static files"-check in the Reports-module shows a somewhat generic warning:

(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.html
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.wrong
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.html.wrong
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.1.svg.wrong
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.2.svg.wrong
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.php.wrong
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.html.txt
(401): http://mydomain.tld/typo3temp/assets/714b0522.tmp/376bc44b.php.txt

One might think that the configuration is unsafe, but in this particular case it was not possible for TYPO3 to perform the checks at all.
I think it would be great if TYPO3 would tell the user, if the check lead to an unexpected result (e.g. wrong content-type) or if it could not be performed at all (where a 401 is the first thing that comes to my mind).

Maybe it would also be useful to do a check on the HTTP-Requests in general, since other parts of TYPO3 also make use of it? (404 handling for example, if you select "Show Content from Page")

Everything connected to HTTP-Requests on itself will fail you create a basic-auth-protection without whitelisting the TYPO3-installation itself (e.g. by whitelisting the server-ip).

tested with 9.5.18, but i 10.4.2+ should also be affected.



Related issues 1 (0 open1 closed)

Follows TYPO3 Core - Task #91354: Integrate server response security checksClosedOliver Hader2020-05-10

Actions #1

Updated by Chris topher about 4 years ago

  • Due date set to 2020-05-11
  • Start date changed from 2020-05-26 to 2020-05-11
  • Follows Task #91354: Integrate server response security checks added
Actions #2

Updated by Stefan P almost 4 years ago

  • Tracker changed from Feature to Bug
  • Subject changed from Improve warnings for "Server Response on static files"-check to Add documentary and improve warnings for "Server Response on static files" check
  • Category set to Reports
  • TYPO3 Version set to 9

Voting for this, too.

Just stumbled over this on a staging environment. Cost me lots of time for debugging what these "warnings" mean. Just to find out that this is because the staging is behind Basic Auth.

But also in general: the check should include a link to the docs (sadly the docs itself do not exist). There's only this (which is not helpful):

The link in there goes to a v10 doc! The v9 doc does not have this section at all. When I'm starting a fresh setup with 9.5.18, I won't look in the changelog, but in the v9 docs of course. From this POV this is an undocumented feature.

I changed this to bug, because the missing v9 doc and/or missleading warnings are a bug, of course.

Actions #3

Updated by Loon Buster about 3 years ago

a feature that protects all developers from the fact that some developers are too incompetent to keep their environment clean is not an enrichment. And again the head-dev's of t3 manage to transfer their own illogic to everyone.

NO conscientious developer leaves such files lying around!


"missing Content-Security-Policy for this location" .. bonkers.

i'm sick of this.


Actions #4

Updated by Christian Ludwig 11 months ago

  • Tracker changed from Bug to Feature
  • TYPO3 Version deleted (9)

I would appreciate a documentation or more informative messages as well because not all of them are self-explanatory.

@Loon Buster

The test for files with two file extensions (like 4d254f98.php.txt) are there to check if the server is configured (by the provider) in a way that these files get executed as PHP. And these files could possibly been uploaded by a TYPO3 user with the right to upload txt files who wants to hack your system.
This already helped me to find out that a well known provider configured his Nginx to forward all Location ~ \.php (no $ at the end) requests to PHP-FPM.


Also available in: Atom PDF