We have struggled with making Atlassian Application Links work with our reverse proxy of the Atlassian applications (Jira, Confluence, BitBucket…) for a long time. The architecture is a very common setup:
Users -> Reverse Proxy (webseal virtual junctions) -> Atlassian Application (Jira, Confluence, BitBucket...)
For example, if user types https://confluence.mydomain.com, the traffics go to the reserver proxy, then get passed to the backend http://confluence.mydomain.internal. Everything works fine in this way except the Application Links. It always fail with the red ‘NETWORK ERROR’ if we configure the reverse proxy address as the application link URL.
The only solution to make it work is to bypass the reverse proxy by host spoofing (e.g /etc/hosts file) or DNS spoofing (e.g private host zone in route 53). Today with some helps I finally find out the root cause, it turns out that the module (atlassian-rest-module) used by the application links does case-sensitive lookup for http headers. That means if the reverse proxy changes http header key like turning the http headers into lower case (e.g Content-Type to content-type), then atlassian-rest-module won’t be able to read the expected header therefore throws the java.lang.NullPointerException error. And in the UI, the error description is something to do with the Unexpected Response.
This is a known bug for Atlassian. And fortunately, it has been fixed recently in the newer version. Please refer the following Jira tickets for details:
- For Jira: https://jira.atlassian.com/browse/JRASERVER-70602
- For Confluence: https://jira.atlassian.com/browse/CONFSERVER-60043
- For BitBucket: https://jira.atlassian.com/browse/BSERV-12470
References:
Application Links Documentations
Bypass Reserver Proxy in Application Links
Application Link Status page fails to load due to Case-sensitive checks for Headers
Jackie Chen's IT Workshop 