I just configured both our JIRA and Confluence to listen on HTTP and HTTPS (they were just listening on HTTP before). But now I am having problems uploading any attachments in Confluence. When I try to upload a file I get the error "The server is not responding. Please check that it is running." But I don't see any errors in the catalina.out file. Everything works fine in JIRA, I can upload attachments in it.
I followed this documentation:
I noticed a difference between configuring JIRA's web.xml file and Confluence's web.xml file.
From JIRA's documentation: "all URLs except attachments are redirected from HTTP to HTTPS."
It looks like Confluence is trying to redirect everything and I'm wondering if this could be related to the issue.
Has anyone gotten Confluence to to listen on both HTTP and HTTPS and not had issues uploading attachements? Thanks for any help.
I figured out a solution to my issue. I found the following errors in my atlassian-confluence.log file:
2017-03-10 16:44:22,674 ERROR [http-nio-8444-exec-3] [confluence.plugins.dragdrop.UploadAction] execute Failed to save file.
-- referer: <obfuscated url> | url: /plugins/drag-and-drop/upload.action | userName: justin | action: upload
java.security.ProviderException: Could not determine buffer size
Caused by: javax.crypto.ShortBufferException: Output buffer must be (at least) 12272 bytes long
... 379 more
Researching, I found a related link: http://stackoverflow.com/questions/38254759/tomcat-8-manager-war-deploy-upload-fails-over-ssl
I tried adding socketBuffer="12272" to my Connector XML entries in my server.xml file but it didn't help. I also tried socketBuffer="-1" but that also didn't help.
The last suggestion about editing the $JAVA_HOME/jre/lib/security/java.security file helped, but required some tweaking. I couldn't just comment out the first provider, like they suggested:
I had to renumber the rest as well.
After changing this and restarting Confluence, I can now upload attachments.
I would revert to standard Tomcat and utilize a proxy like Apache/nginx to handle HTTPS in between the servers or on them.
This way you can terminate the SSL directly there and do some other good stuff. Else if you continue with Tomcat I hope you will figure it out
Thanks, yes we have F5s sitting in front of everything. Up until now, we've had it configured so that the connection between the client and the F5 is encrypted, but the connection between the F5 and the backend servers is unencrypted. I have been working toward encrypting that backend connection. But with all of the work and problems I've run into so far I am starting to regret going down that path.
I did find out a solution to this particular issue though (see below). It was pretty obscure.
More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs