Add a default Contao backend favicon to prevent log spamming

[Defcon0]

Hello,

we often have the problem that logs get "spammed" with 404s that result from a missing favicon.ico located in the web folder.

Would it be an option to add a default contao favicon file in order to prevent that (and to make clearer that you are working with contao ^^)? I personally prefer to have a different icons in backend and frontend.

Thanks!

Bye Defcon0

[aschempp]

Why not add a real favicon? What Contao version do you use?

[Defcon0]

Why not add a real favicon?

->

I personally prefer to have a different icons in backend and frontend. [...] and to make clearer that you are working with contao ^^

Also if a default icon comes with contao, the dev can't forget this.

In this case: Contao 4.4

[Toflar]

4.9 already provides that functionality.

[Defcon0]

Ah ok. Then it's ok I guess since we're upgrading to 4.9 anyway. Thanks for the hint.

[Defcon0]

Mhm, just tested that but at least in 4.9.2 there's no favicon.ico in the web root by default.

In fact the request doesn't even come from the html but from chrome:

https://stackoverflow.com/questions/30693021/chrome-developer-tools-shows-favicon-404-error-in-brackets-livepreview

But the result nevertheless is that tons of 404s are spammed to the logs if no favicon is added.

Am I missing something?

[Toflar]

You can choose it in the website root so you can have different ones per domain.

[Defcon0]

Got that, but my question concerned a default favicon.ico if the developer doesn't specify one.

[fritzmg]

Related:

• Favicon in backend causes usability glitches core-bundle#958
• [RFC] (Re)add a grey favicon for the backend core-bundle#963

[m-vo]

Got that, but my question concerned a default favicon.ico if the developer doesn't specify one.

Considering the broken/ignorant caching strategy of favicons across most browsers, this probably isn't a good idea.

[Defcon0]

Well, but currently the consequence is that we have thousands of 404s in the logs which is pollution. Each and every request to any site in backend produces this 404 for each and every user. In large pages this can get grow large after a while.

I know, I can add the favicon, but it would be better to have that by default imho.

[leofeyer]

Maybe we should not log failing requests for a non-existing favicon. Just like you would configure your web server, e.g. Nginx:

location = /favicon.ico {
  access_log off;
  log_not_found off;
}

[Defcon0]

That would becan option, I think.

[Anke]

I just updated a site from 4.8.7 to 4.9.4. with the maintenance mode on. Checking the updated website I saw that some preview pictures were not shown in the Isotope shop. Clicking on one of their placeholders I got the Contao error page. The log file says:

[2020-07-27 15:45:14] request.INFO: Matched route "contao_core_favicon__invoke". {"route":"contao_core_favicon__invoke","route_parameters":{"_route":"contao_core_favicon__invoke","_scope":"frontend","_controller":"Contao\\CoreBundle\\Controller\\FaviconController"},"request_uri":"https://www.hbf-reinigungsgeraete.de/favicon.ico","method":"GET"} []
[2020-07-27 15:45:14] security.INFO: Populated the TokenStorage with an anonymous Token. [] []
[2020-07-27 15:45:14] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException: "Service Temporarily Unavailable" at /kunden/370127_65205/webseiten/Contao4/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php line 100 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\ServiceUnavailableHttpException(code: 0): Service Temporarily Unavailable at /kunden/370127_65205/webseiten/Contao4/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:100, Lexik\\Bundle\\MaintenanceBundle\\Exception\\ServiceUnavailableException(code: 0): Service Temporarily Unavailable at /kunden/370127_65205/webseiten/Contao4/vendor/lexik/maintenance-bundle/Listener/MaintenanceListener.php:206)"} []

With the maintenance mode disabled there are no errors. I'm aware that these might be two different issues, but I don't know which might possibly be causing which.

[fritzmg]

@Anke your issue is unrelated. And the error message you posted is unrelated to your issue.

[leofeyer]

@Defcon0 I actually cannot reproduce the issue. Chrome shows a 404 response for the /favicon.ico route, however, there are no log entries neither in var/log nor in the system log in the back end. Did you modify the logger configuration? Because 404 error are excluded from logging by default:

contao/manager-bundle/src/Resources/skeleton/config/config_prod.yml

Line 18 in de2a224

excluded_http_codes: [400, 401, 403, 404]

[Defcon0]

Strange. I only get it in prod mode (contao 4.4.49):

[2020-08-05 09:06:19] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "Page not found: http://www.corporate.acme.hhdev/favicon.ico" at /home/dev/Kunden/acme/corporate/produkte/contao/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php line 112 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException(code: 0): Page not found: http://www.corporate.acme.hhdev/favicon.ico at /home/dev/Kunden/acme/corporate/produkte/contao/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:112, Contao\\CoreBundle\\Exception\\PageNotFoundException(code: 0): Page not found: http://www.corporate.acme.hhdev/favicon.ico at /home/dev/Kunden/acme/corporate/produkte/contao/vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:63)"} []

I didn't change the logger config. Here's my project's config.yml:

contao:
  url_suffix: '' # do not add .html to urls
  prepend_locale: true
  image:
    bypass_cache: false # bypass image cache while in dev mode

framework:
  assets:
    json_manifest_path: '%kernel.project_dir%/web/build/manifest.json'
  translator: { fallbacks: [de] }
  default_locale: de
  session:
    gc_probability: null

huh_maildrum:
  useContaoCron: true

[fritzmg]

@Defcon0 I actually cannot reproduce the issue. Chrome shows a 404 response for the /favicon.ico route, however, there are no log entries neither in var/log nor in the system log in the back end. Did you modify the logger configuration? Because 404 error are excluded from logging by default:

@leofeyer this is for Contao 4.4, not 4.9. In Contao 4.4, 404 requests are logged.

@Defcon0 please always provide the minimum amount of information required when posting a new ticket.

[leofeyer]

@leofeyer this is for Contao 4.4, not 4.9. In Contao 4.4, 404 requests are logged.

That does not make sense, either, because in Contao 4.4, we do not have a dynamic route for /favicon.ico, hence the request should not be handled by Contao at all.

[fritzmg]

Any request, that does refer to a physical location, is handled by Contao. And since the resource at https://example.org/favicon.ico does not physically exist, the request is handled by PHP, i.e. Contao, due to the .htaccess (or nginx) rules. And since Contao will not find a resource/page under this URL, the 404 page is generated and the 404 response is logged.

[leofeyer]

This is not limited to favicon.ico request, is it? Basically any request for an unknown resource (e.g. foo.jpg, foo.bar, etc.) will end up in a 404 response that gets logged, as long as every request is routed through the application. So I do not think that we can do much about this, except agreeing not to log 404 responses anymore. @contao/developers WDYT?

[Defcon0]

I‘d prefer to add a yml option not to log 404s anymore. In most cases 404s from bots or MS exchange and so on are stored in the logs hiding the more relevant things like exceptions.

The option should be to log them per default still for BC reasons.

[fritzmg]

So I do not think that we can do much about this, except agreeing not to log 404 responses anymore.

Which is already the case in Contao 4.9 anyway. However, the Monolog option exclude_http_codes is only available in Symfony 4.4+, thus we cannot use it in Contao 4.4.

[aschempp]

can this issue be closed then?

[Defcon0]

I think so, if it's the case in contao 4.9, that's enough for me, at least ;) Don't know if anyone disagrees?