Still detected by the log scanner in 8.x, even though it doesn't seem to occur.

Hi Support,

Why this issue is still seen in DC LTS v7.19.17?

Still in 8.5.4

Even though the emoticons appear to be shown correctly.

8.5.4 also

Still seeing this in 8.5.3

Also observed in 7.19.14 DC

I see this error pop up for Confluence 8.5.1

We see this in Confluence 7.19.12

We see this in Confluence 7.19.5
 

Message still existing in confluence-stderr.log of Confluence Server 8.0.1

We see this in Confluence 7.19.4

Message coming with 7.19.2 as well.

Having the same message in log analyzer in 7.19.0 as well.

Same here. Confluence 7.13.7 and the Log Analyzer shows 

Having this in the Log Analyzer with 1 recent occurence in LTS 7.13.7, too. Standard install, no custom tomcat updates or the like.

I just upgraded from 7.4.6 to 7.13.7 and this error appears in my post upgrade log analyzer. Apache Tomcat/9.0.63. Can't actually reproduce the problem, though.

I have version Confluence 7.4.9 and Tomcat version 9.0.40 

Why do I get this error when analyzing the log ?

If you have Apache HTTPd before Confluence, you can fix all the issue by adding these lines to the VirtualHost configuration:

...
SetEnvIf Request_URI "\.svg[z]*$" fix_svg
Header set Content-Type "image/svg+xml;charset=UTF-8" env=fix_svg
</VirtualHost>

Just updated Tomcat from version 9.0.11 to 9.0.65 in Confluence 6.11.2 and the issue has gone away after this change.
I believe this will work for any other Confluence and Tomcat versions.

Hi Team,

above mentioned 

Environment

• Confluence 6.15.3 tomcat 9.0.17

What about "Confluence version ??  with tomcat 9.0.20 and higher?

This seems to be occurring in earlier versions of Tomcat as well.  We're currently on 8.5.6 and since upgrading to Confluence 6.15.3 we're experiencing the same problem.

A fix for this issue is available to Server and Data Center customers in Confluence 6.10.3
Upgrade now or check out the Release Notes to see what other issues are resolved.

If you're running the Confluence 6.6 Enterprise release, a fix for this issue is now available in Confluence 6.6.14, which you can find in the Download Archives.

If you're running the Confluence 6.13 Enterprise release, a fix for this issue is now available in Confluence 6.13.5, which you can find in the Download Archives.

A fix for this issue is available to Server and Data Center customers in Confluence 6.13.5
Upgrade now or check out the Release Notes to see what other issues are resolved.

If you're running the Confluence 6.6 Enterprise release, a fix for this issue is now available in Confluence 6.6.14, which you can find in the Download Archives.

If you're running the Confluence 6.13 Enterprise release, a fix for this issue is now available in Confluence 6.13.5, which you can find in the Download Archives.

Hi All,

I've been reviewing this issue and had a couple of points I wanted to touch base on.

florian.rock2 marc.richter both queried why a bug fix release of Confluence contained an upgrade to Tomcat.
Confluence 6.15.3 contained the following fix CONFSERVER-58106: Update Confluence Server to use Tomcat 9.0.16 to address CVE-2019-0199 (fixed in Confluence Server 7.0.1, 6.15.3, 6.14.4, 6.13.5, 6.6.14, 6.15.4). As the title indicates, it's resolving a CVE in Tomcat that can be viewed at CVE-2019-0199. This upgrade was from Tomcat 9.0.12 to 9.0.16, which is, in turn, a bug fix release. The full release notes can be found at Apache Tomcat 9 - Changelog.

The Tomcat bug fix release 9.0.14 contained a significant change in behaviour, described as The default Servlet should not override a previously set content-type.. This change is what broke SVG images in Confluence 6.15.3. Basically, the change was a Tomcat bug fix upgrade to fix a security bug, and is appropriate for a Confluence bug fix release.

Obviously this was a miss on our part, in that the bug wasn't caught prior to release, but I just wanted to address the specific point raised. The incident has been reviewed by our teams internally, and we're adjusting our testing and release process to ensure this doesn't happen again.

gatis.rumbens31991816 zcalusic2116158691 both provided feedback on the removal of Confluence 6.15.3 from download.
Firstly, we appreciate you taking the time to provide feedback. Obviously issues like this one provide a difficult position for our users, and in this case we prioritised removing the build to avoid additional customers being impacted by the issue.

I understand in some situations this has made life harder that anticipated for some of our users, and I've flagged your comments for review internally.

francois.jean2130393706 queried the severity assigned to the ticket.
This ticket was originally raised on behalf of a customer who had manually upgraded Tomcat inside of Confluence 6.13.4 to Tomcat version 9.0.14. As a result, it wasn't actually a bug in Confluence at the time. Thus the low severity rating.

When Confluence 6.15.3 shipped with the changed behaviour in Tomcat, this ticket was identified as being the same issue, but now present in Confluence. It was subsequently adjusted to reflect this issue, including a High priority rating.

java -cp catalina.jar org.apache.catalina.util.ServerInfo

As always, we appreciate the contributions of everyone on this ticket, both in helping one another and us in working around and resolving the issue.

Thanks,
James Ponting
Premier Support Engineer

Hi Charan,

are you sure this is related to this issue? Please check, if you see a protocol switch from https to http when opening a page where you see the problem (Browser console F12). 

Please check https://jira.atlassian.com/browse/CONFSERVER-57934 if this related to your issue.

Best

JP

Hello All,

After upgrading to 6.15.4 we started facing broken images. and yes we use Apache tomcat 9.0.19 which mention in ticket. Do we have to wait until the next release of 6.15.4? or any temp workaround is there to fix this issues? 

Regards,

Charan N

A fix for this issue is available to Server and Data Center customers in Confluence 6.6.14
Upgrade now or check out the Release Notes to see what other issues are resolved.

If you're running the Confluence 6.6 Enterprise release, a fix for this issue is now available in Confluence 6.6.14, which you can find in the Download Archives.

thanks for your effort,  @Jan-Peter Rusch

Hi all,

Atlassian is tracking the protocol switch issue on:

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

I added a more generic way to force the error by copying the steps of Boerner to this issue.

Vote & watch

JP

Hi all,

short update. I'm in contact with support & waiting for a confirmation of the protocol switch issue. I copied the comment of Boerner:

https://jira.atlassian.com/browse/CONFSERVER-58180?focusedCommentId=1977544&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1977544

which is a way reproduce the bug.

I keep you updated.

For mixed content, you might want to look at this issue: CONFSERVER-52441.

Hi,

we use an Apache server with https as reverse proxy as well. Now, with Confluence server 6.15.4. having Emoticons on the page mozilla firefox browser says that some parts of the page are potentially insecure, e.g. images. Deleting all Emoticons resolves the problem, i.e. the browser information state returns back to the green lock.

Thanks Jan-Peter Rusch....

Hi Chris,

I opened a ticket with the Atlassian support referencing this issue. I'll keep you updated unless Atlassian staff is adding some comments here....

Were is the bug raised for the https -> http redirection error?

This is effecting us, we don't use reverse proxy due to performance issues. When is Atlassian fixing this bug?

Hi,

I can confirm the https to http redirection error with 6.15.4 on svg files/images

We use an Apache reverse proxy doing an automatic internal redirect (HTTP Code 307), so there is no error message on mixed content.

I'll raise a support ticket with Atlassian to make them aware of the bug.

@Kristaps thanks for your investigation and that hint. This is can be a workaround .
But that would confirm, that there is still a bug? How to make Atlassian aware of it?

*we just had a mistake in our Apache rewrite rule and had to adjust it from

RewriteRule ^(.*)$ https://confluence.mypage.com/

to

RewriteRule ^(.*)$ https://confluence.mypage.com/%{REQUEST_URI}

Thats indeed the case here as well, about the mixed content.

We have an nginx reverse proxy for handling http>https redirects. It turns out that all those emote icons with http urls get correctly redirected to https urls. I think thats why we dont have such issue with broken emote icons on edit page as you both have.

same issue happening in 6.15.4 as Boerner mentioned , go to chrome developer tools --> security tab , there is a complain about mixed content , using firefox it displays the warning in the address bar

yes for both questions. (All other things are working fine, I didnt got any complaints (from our 30-40 users), despite the emote-thing.)
The server was restarted last night

Is the base url in general settings having https in front?
Do you have https scheme enforced in <confluence install>/conf/server.xml?

Oberservation:

1) insert an image and save the page

2) right klick on the image > "copy image address" -> http*s*://confluence.mypage.com/.../_/images/icons/emoticons/forbidden.svg

3) edit the page (the image is still there) and save the page

4) right klick on the now broken image > "copy image address" -> *http://*confluence.mypage.com/.../_/images/icons/emoticons/forbidden.svg

So after saving the second time, the editor changes the imagelink from https to http and the browser complains about "mixed content" which it doesnt want to load.

(could it be the apache reverse proxy? but why would it fail only after the second edit)

@kristaps thank you, for your reply. We cant really retrace, if this Problem was already seen with 6.15.1. It was first reported to me on April, 15th.
So we installed 6.15.3 -> bigger problems, and we hoped, that this would be resolved wih 6.15.4.
I don't know how to troubleshoot this issue. Somehow both problems (the behaviour in the GIF and the problem, introduced with 6.15.3) have to do with the emotes. I dont think, this is a coincidence?!

@Boerner, I just tried the same thing as in your GIF and it did work fine for me. Version 6.15.4

I installed 6.15.4 yesterday. Thank you for the fast fix.

Unfortunately, when you save the page after inserting an emote and edit it again, the emote is destroyed ...

here is a GIF to explain:

ok, I can't upload a file

so, here is a link to the GIF: https://gofile.io/?c=tC8QMa https://gofile.io/?c=tC8QMa

Already contacted the Conlfuence support.

https://getsupport.atlassian.com/servicedesk/customer/portal/14/CSP-251348

After verifying on 6.15.2 I couldn't reproduce this issue.

tpham3 - can you please contact support with more details?

Thank you 

I upgraded the my Confluence sever from 6.1.0 to 6.15.2 two weeks ago and now I am having the problem with the Emoticons. As I checked,  the Tomcat with Confluence-6.15.2 is 9.0.12 . With that said, downgrade to 6.15.2 will not do any good. I am very disappointed with Atlassian QA team. 

A fix for this issue is available to Server and Data Center customers in Confluence 6.15.4.

Upgrade now or check out the Confluence 6.15 Release Notes to see what other issues are resolved.

I must agree with @Gatis Rumbens on all accounts, and I think Atlassian is doing lousy job here.

1. released version is a RELEASED version, you don't just delete it 'cause it has bugs (ALL versions have bugs, after all... why then not delete them all?)
2. you fix it by releasing a NEW version, with the hotfix, that's what EVERYBODY does (that is, everybody except Atlassian, WHY?) - and you just flag the buggy version with "DO NOT USE" flag, we can read
3. you DON'T prevent your users to downgrade to a lesser minor version, that's what minor versions are for, if the new one is buggy, revert to the last working one (and NO, that shouldn't mean rebuilding database from the last backup)

In this container age, we're accustomed to move among software versions fast and painlessly. When will Atlassian adopt new DevOps paradigms? I've even seen newsletters sent by Atlassian about DevOps, but the question is when will THEY start using those ideas?

P.S. Somehow I WAS able to revert back to 6.15.2 without database reload, after seeing how non-functional 6.15.3 was

P.S. #2 The other time I was not so lucky, had to revert to last nights backup of Jira database, just to revert one MINOR version, 'cause the latest had some grave bugs and was completely non-functional. I was so pissed off with the whole procedure and wasted time required to get back to working version.

P.P.S. #3 I guess this is what means to add insult to injury, first they ship a version with grave bugs, then they remove that release like it never existed (feeling guilty, hiding tracks, pretending it never happened?) and leave you in a limbo, then they eventually prevent you to easily downgrade, forcing you to reload the whole database.

I can't believe, that this version was released with such a bug. Atlassian does not have some pre-release tests to prevent this?!

I'm a little confused - cause in Atlassian's RSS feed for new versions of the product has a new record for 6.15.2 and 6.15.3 was withdrawn

The 6.15.3 version has disappeared under downloads - instead it is 6.15.2 now.

Instead of release the patch or the fixed version with the build number 6.15.4 - it's rolled back the previous version.

As we know the Atlassian Confluence does not allow to perform rollback to an older version in the normal way.
Quoting Atlassian:

Atlassian doesn't provide a tool for downgrading or rolling back to a previous version of Confluence. Once the upgrade is done, it can't be undone.

Of course I know the way in which I can return to version 6.15.2 by replacing Tomcat libraries and binaries. But in my opinion -> this is not correct way.
For now, I'll stay on header rewrite solution and I'm waiting for the new version

Will the fix be released this week? In a V.6.15.4? ...I am in progress of update change planning (scheduling that for the next few days) and have to decide which confluence version I can use.

Thanks for the Workaround, it works on Ubuntu 18 with nginx as reverse proxy. I hope a bug-fix version doesn't take too long

NGINX as reverse proxy solution if Confluence and NGINX is on the same box

location ~ .(svg)$ {
        proxy_hide_header Content-Type;
        add_header Content-Type image/svg+xml;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:8090;
} 

We have the same issue after upgrading to 6.15.3 , any .svg file (default avatars, emoticons etc)  are not displaying (depending on which browser, an alt_text or blanks are displayed instead)

fixed by copying over the <confluence_install>/bin and <confluence_install>/lib files from version 6.15.2 to the respective directories in 6.15.13 and overwriting followed by clearing the browser cache.

david.bonavila depends on your distribution if a2enmod works. but could be

Mod_header is save and standard mod of Apache:
https://httpd.apache.org/docs/2.4/mod/mod_headers.html

you can enable the module without apache restart.. a reload should work.

And the good thing about reload is that it checks the config in advance and wont break

Thanks @florian.rock2 @Florian Rock.

I do not currently have mod_headers enabled on apache2. I use apache as a reverse proxy for Confluence.

Enabling mod_headers (with "a2enmod headers" I assume) will not break anything on my Confluence server or apache reverse proxy?

Thanks florian.rock2 for the workaround. works!