APM sends local favicon.ico to client instead of fetching it from the backend

[Peter_Baumann]

This behavior seems to be since 16.1.2 and 16.1.3 version upgrade. The APM is sending the local version of favicon.ico to the client and not the version of the backend after the session has established.
The used access profile is in LTM+APM mode.
It seems to be a bug like this here: Bug ID 617675: SWG sends local favicon.ico to client instead of fetching it from the backend server 
We already tried the provided irule as a workaround but it doesnt work (redirect to somefavicon.ico etc.)

Has someone experienced the same problem?

Many thanks,
Peter

[Lucas_Thompson]

Hi Peter.

Your browser probably grabs the favicon upon visiting the APM virtual server, and doesn't try to get it again once authenticated. You can change the favicon content by adding an iRule that basically says "if I hear a request for this URL, then serve out this file content" by following this KB:

https://support.f5.com/csp/article/K25815544

There are other touch-icon favicons that Apple uses too and you can use the same technique.

[Peter_Baumann]

Hi @Lucas_Thompson ,
This looks good but there's one problem:
We have an APM application which will be served after login and we need the favicon from this backend app after login.
This is exactly not working and we always get the default favicon of APM back to the client.
The backend apps are always changing since this vs with APM policy is doing SAML SSO.

So, any idea how to get the favicon.ico of the backend to the client?

Thank you.

[Lucas_Thompson]

In this case you'd like the favicon to be transmitted to the client ONLY once they are succesfully authenticated? Something like this should work (for LTM+APM mode), it says basically "If there is no session and the user is requesting favicon, then send a 404 instead of the APM favicon."

I'm not exactly sure if the best bet is a 404 or something different, but because you don't know in advance what backend host should get the favicon request, you're forced to send some static content or error.

Please also note that this irule uses the "ACCESS::restrict_irule_events disable" command which causes the HTTP_REQUEST event to fire upon each access, rather than the default behavior of only firing on the non-built-in APM HTTP requests (such as for webtop, logon pages, SAML URIs, etc). Make sure you don't have any other irules with HTTP_REQUEST events that might interfere with user logons.

when CLIENT_ACCEPTED {
  ACCESS::restrict_irule_events disable
}

when HTTP_REQUEST {
  if { [HTTP::cookie exists "MRHSession" ] && [ACCESS::session exists -state_allow] } {
  # user seems to have a valid session, let them get the backend resource
  return
} else {
  if { [HTTP::uri] contains "favicon" } {
    # remove the following log line after testing
    log local0. "user has no session, sending 404 for favicon request"
    HTTP::close
    HTTP::respond 404
    }
  }
}

[Peter_Baumann]

Hi @Lucas_Thompson ,
Unfortunately it still doesn't work. But your iRule seems to do the right thing, thank you for that!
When I don't have a session I get the 404 back as seen in devtools from the browser.
When I have a session I get the favicon.ico but not from the backend.
It still uses the default icon from APM:

I have seen this now at other customer installations. For me this seems to be a bug in APM not sending the favicon.ico from the backend to the client.

Thanks,
Peter

[Lucas_Thompson]

Thanks for the quick feedback, it sounds like we're on the right track.

So, in your situation where APM doesn't know what backend to use because it's dynamic and the user has not yet logged in, what favicon (or HTTP error or whatever?) should APM send? We can make the iRule do anything we want, as long as we can precisely define what we want it to do.

By default APM sends its own favicon because the browser requests it right away on the site BEFORE logging it at all, and we definitely wouldn't want to leak files from the backend prior to APM auth, at least by default.

[Riemen]

We have also encountered this problem with the favicon when APM is active on a virtual server.

We run a productive webshop where single URI Pathes are protected by APM.
For this the APM is switched on in the VS as well as an iRule that ACCESS::enable only the specified uri paths.
Everything else is default ACCESS::disable

This works for all requests, traceable in the LTM log, but especially /favicon.ico is still stopped by APM and the requests do not reach the LTM Policy.

https://my.f5.com/manage/s/article/K25815544
This does work, but is only a Workaround. I dont want to Host the favicon.ico on the F5.

Looks like a Bug from my view.