Kibana should NOT return 302 for /favicon.ico

[vbohata]

Describe the feature:
Kibana returns 404 for /favicon.ico if the user is already authenticated. In other case browser receives 302 with redirection to /login?next=%2Ffavicon.ico. It makes problems with Kibana published using some external authenticating proxy because:

1. If accessing https://kibanaurl with firefox, firefox actually creates 2 requests - one to https://kibanaurl and the second one to https://kibanaurl/favicon.ico
2. Authenticating proxy returns its login form to the user while returning 302 and 200 for /favicon.ico from backend.
3. Browser caches 200 for /favicon.ico
4. After logging in in auth proxy user is redirected to Kibana https://kibanaurl/login?next=%2Ffavicon.ico
5. User authenticates in Kibana and is redirected by Kibana to https://kibanaurl/favicon.ico which does not exist

Describe a specific use case for the feature:
One of the use case is webseal publishing. See https://www.ibm.com/support/knowledgecenter/ja/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_webseal_admin138.htm
It is expected the backend always returns 404 for favicon.ico to fix the firefox behaviour. But currently it is not true for login form of Kibana as it catches /favicon.ico and returns 302 to the browser.

[elasticmachine]

Pinging @elastic/kibana-operations

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lukeelmers]

We could probably do this by allowing unauthenticated access to all ui assets (need to confirm this is okay to do)

https://github.com/elastic/kibana/blob/main/src/core/server/core_app/core_app.ts#L199

[gsoldevila]

FWIW I think recent browser versions don't request the favicon.ico anymore (tested with Firefox 102 and Chrome 103 in local and cloud).

What about "simply" adding the missing favicon.ico file? This way we don't need to change anything security-wise because the file will actually exist and it will be simply served.