SVG icons/emoticons are not shown after installing Confluence server

[adrian.hernandez-mendez]

After the installation of Confluence server, some SVG icons ( e.g., the ones in the path: _/images/icons/emoticons/ ) are not displayed in the admin pages. The server can resolve the icons URL when the URL is copied directly in the browser, however they are not rendered in the <img> tag.  This behaviour it is observed in  Firefox, Chrome and Safari.

This problem is similar to the one described in broken-avatars-icons-in-confluence-after-an-upgrade, I've tried the proposed solution, but unfortunately it didn't work for me. Additionally, the src attribute in the <img> has the right path for the image.

Any ideas how to solve this problem ?

[jtaala · Accepted solution]

Turns out this is caused by a recent change in tomcat. See:

https://jira.atlassian.com/browse/CONFSERVER-58180

Fix/workaround is to downgrade to tomcat 9.0.13 following: 

https://confluence.atlassian.com/confkb/how-to-upgrade-the-tomcat-container-for-confluence-336757062.html

[Lukas Walla]

thank you very much for your help. I just tried to downgrade Tomcat, as you suggested, but unfortunately the issue persists. I even tried the other steps to resolve the issue again (empty cache, reindex etc.) but no change. Looks like there is more involved than just the tomcat version.

[jtaala]

Hi Lukas,

I should note that I did need to clear my browser cache before I could confirm that it resolved the issue.  Could you double-check by opening a new incognito window and rechecking if it's resolved?

I can confirm this did indeed workaround the issue on a recently upgraded 6.15.3 confluence instance that had identical issues as described in this thread.

I actually used another workaround for my other 6.15.3 confluence (production) instance that I am not in a position to shutdown (until perhaps this weekend):

If you use a reverse-proxy to SSL confluence (such as apache or nginx) you can override the header for all requests to svg (icons) by adding the following to your vhost (if using apache 2.4):

<If "%{REQUEST_URI} =~ /.*\.svg/">
  Header set Content-Type "image/svg+xml;charset=UTF-8"
</If>

There is an equivalent override for nginx.

E.g. my apache (2.4) reverse proxy for my confluence virtual host looks like:

<VirtualHost *:443>
ServerName confluence.example.com

ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1

RewriteEngine On

<If "%{REQUEST_URI} =~ /.*\.svg/">
Header set Content-Type "image/svg+xml;charset=UTF-8"
</If>

RewriteCond %{REQUEST_URI} !^/synchrony
RewriteRule ^/(.*) http://127.0.0.1:8090/$1 [P]

ProxyPass /synchrony http://127.0.0.1:8091/synchrony
<Location /synchrony>
Require all granted
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:8091%{REQUEST_URI} [P]
</Location>

ProxyPass / http://127.0.0.1:8090/
ProxyPassReverse / http://127.0.0.1:8090/

..."SSL cert stuff goes here"...

</VirtualHost>

 Hope this might help.

Jay.

[jtaala]

Hi Lukas,

I should note that I did need to clear my browser cache before I could confirm that it resolved the issue.  Could you double-check by opening a new incognito window and rechecking if it's resolved?

I can confirm this did indeed workaround the issue on a recently upgraded 6.15.3 confluence instance that had identical issues as described in this thread.

I actually used another workaround for my other 6.15.3 confluence (production) instance that I am not in a position to shutdown (until perhaps this weekend):

If you use a reverse-proxy to SSL confluence (such as apache or nginx) you can override the header for all requests to svg (icons) by adding the following to your vhost (if using apache 2.4):

<If "%{REQUEST_URI} =~ /.*\.svg/">
  Header set Content-Type "image/svg+xml;charset=UTF-8"
</If>

There is an equivalent override for nginx.

E.g. my apache (2.4) reverse proxy for my confluence virtual host looks like:

<VirtualHost *:443>
ServerName confluence.example.com

ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1

RewriteEngine On

<If "%{REQUEST_URI} =~ /.*\.svg/">
Header set Content-Type "image/svg+xml;charset=UTF-8"
</If>

RewriteCond %{REQUEST_URI} !^/synchrony
RewriteRule ^/(.*) http://127.0.0.1:8090/$1 [P]

ProxyPass /synchrony http://127.0.0.1:8091/synchrony
<Location /synchrony>
Require all granted
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:8091%{REQUEST_URI} [P]
</Location>

ProxyPass / http://127.0.0.1:8090/
ProxyPassReverse / http://127.0.0.1:8090/

..."SSL cert stuff goes here"...

</VirtualHost>

 Hope this might help.

Jay.

[Lukas Walla]

Hi Jay,

you're a genius - that was the missing part (should have thought about it myself...). Downgrading Tomcat in combination with clearing browser cache was the solution!
Thank you very much for your help! Very much appreciated.

best regards

Lukas

[adrian.hernandez-mendez]

Thanks Jay for describing the issue and possible solutions, I downgraded to the version 6.15.2 and the issue disappear. Looks like sometimes is not the latest version the best option to use ;-) 

[Guido Jäkel]

Dear Jay,

you save my day!!

But as I'm not using the bundled Tomcat, but a farm using Tomcat-8.5.38 at the moment, I would like to ask what is the core reason of the issue?

At https://jira.atlassian.com/browse/CONFSERVER-58180 I read:

I checked the release notes for Tomcat 9.0.14, and it looks like the issue is caused by this change: "The default Servlet should not override a previously set content-type"

This sounds to me if it's a valid upstream bugfix and the issue is triggered by Confluence by setting an inproper MIME type which isn't overriden anymore.

Is this the truth?

[jtaala]

Yes, that was exactly the issue.  Atlassian have released 6.5.14 which resolves the issue.

[Guido Jäkel]

Upgrading from 5.5 this days, we decide to upgrade to the Enterprise line. Therefore, I choose 6.13.4 to install. Does 6.15.4 really fix the issue withing Confluence or have Atlassian "fixed" it  by just choosing an older Tomcat version?

[jtaala]

That's a very good question.  I'm planning on upgrading once of my confluence instances to 6.5.14 this weekend and will find out then.

Although, looking at recent comments on https://jira.atlassian.com/browse/CONFSERVER-58180 6.5.14 has an issue now with browsers now showing an insecure content warning with emoticons not redirecting to https (which can be worked around with another apache workaround...)... I say stick with 6.13.4 for the time being.

[jtaala]

Hey all,

You're definitely not alone.  Two separate and independent confluence instances of mine have the same issue after upgrading to 6.15.3 (plus emoticons not rendering at all).

Also see https://community.atlassian.com/t5/Confluence-questions/Standard-Emoticons-show-as-broken-after-re-install-and-import/qaq-p/1070965#U1072068

[Lukas Walla]

unfortunately I cannot provide a solution for this issue, but I can confirm it. I was migrating my Confluence instance to a new server and got the exact same problem. Some Icons are broken, but definitely not all of them: the emoticons as well as the icons in the global permission section are broken. But others like the permission icons on the space permission dialog (which are the same as on the other permission section) are there. On some spaces also the default avatar does not work.
I did a migration from 6.11.x (old server) to 6.15.3 (new server) with restoring a backup of the data. I tried the proposed solution but absolutely no effekt. In addition I later did an upgrade on the old server und got the same issue there. So upgrading and restoring an instance on a brand new installation shows the same problem. Looks to me like a bug! Unfortunately I cannot open a ticket as I only have a starter license.
Would be awsome if somebody could help