Jira and Bitbucket menu item URL issues with IIS reverse proxy

[John Petrou]

Both Jira 8.18.1 and Bitbucket 7.14.1 have been setup behind an IIS reverse proxy.  Both seem to work except for some links in both applications repeating the context path twice. Other links are as expected. The applications have been set up to be accessible externally via the company URL and a context path. i.e https://www.mycompany.com.au:8443/jira and https://www.mycompany.com.au:8443/bitbucket.  I can access both apps and log in but when a menu link is clicked some will show a repeated context path: e.g. the following URL is shown

 https://www.mycompany.com.au:8443/jira/jira/secure/project/BrowseProjects.jspa?s=view_projects

when I click the Projects menu item under settings.  Other menu items do not show this repeated context path. For example all menu items from any of the menus in the Dashboard view have the expected URLs. However the top level menu links on this page show this behaviour when I hover over them.

I have tried deleting the context path from the server config files and then I can't access the apps at all.  I have tried changing the base URL to exclude the context path but have issues with accessing widgets.

Config file contents:

Jira

< Connector port="9080"
   relaxedPathChars="[]|"
   relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
   maxThreads="150"
   minSpareThreads="25"
   connectionTimeout="20000"
   enableLookups="false"
   maxHttpHeaderSize="8192"
   protocol="HTTP/1.1"
   useBodyEncodingForURI="true"
   redirectPort="8443"
   acceptCount="100"
   disableUploadTimeout="true"
   bindOnInit="false"  
   proxyName="www.mycompany.com.au"
   proxyPort="8443"
   scheme="https" />

<Context 
path="/jira" docBase="${catalina.home}/atlassian-jira" reloadable="false" useHttpOnly="true">
   <Resource name="UserTransaction" auth="Container" type="javax.transaction.UserTransaction"
       factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60"/>
   <Manager pathname=""/>
   <JarScanner scanManifest="false"/>
   <Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="120" />
</Context>

Bitbucket

server.context-path=/bitbucket
server.secure=true
server.scheme=https
server.proxy-port=8443
server.proxy-name=www.mycompany.com.au

I'm not sure what to try next.  Has anybody else seen this behaviour? I have searched but can't find a similar problem.  There are some rules that modify URLs for outbound responses in my URLrewrite settings but the double URL links show in a browser even when I hover over the menu items so there has been no opportunity for the link addresses to be modified.  Any suggestions would be greatly appreciated.

[John Petrou · Accepted solution]

I have found the issue that caused this behaviour.  For those who are interested, it WAS the IIS re-write rules.  The outbound rules were adding the context path and so was tomcat when set up to run behind a reverse proxy.

the offending rules were:

<outboundRules>
   <rule name="Add application prefix" preCondition="isHTML" enabled="false">
      <match filterByTags="A" pattern="^/(.*)" />
      <conditions>
         <add input="{URL}" pattern="^/(jira|bitbucket)/.*" />
      </conditions>
      <action type="Rewrite" value="/{C:1}/{R:1}" />
   </rule>
   <rule name="Rewrite Location Header" preCondition="IsRedirection" enabled="false">
      <match serverVariable="{RESPONSE_LOCATION}" pattern="^http://[^/]+/(.*)" />
      <conditions>
         <add input="{ORIGINAL_HOST}" pattern=".+" />
         <add input="{URL}" pattern="^/(jira|bitbucket)/.*" />
      </conditions>
      <action type="Rewrite" value="https://{ORIGINAL_HOST}/{R:1}" />
   </rule>
   <preConditions>
      <preCondition name="isHTML">
         <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
      </preCondition>
      <preCondition name="IsRedirection">
        <add input="{RESPONSE_STATUS}" pattern="3\d\d" />
      </preCondition>
   </preConditions>
</outboundRules>

{ORIGINAL_HOST} was captured in the inbound rules

Once these two rules were disabled, everything worked as expected.  Hope this helps someone else.