New installation - Jira - Logout option returns 400 Error

New installation has been done.  we have noticed that when logging out of the application, it returns a 400 Error.

Jira Version 7.5.2

Apache Tomcat Version 8.5.23

If I remove the atl_token string, I get the page I would expect.



5 answers

0 votes

Hi Damian,

I also did a fresh install of 7.5.2, but I was not able to reproduce the problem you report here.   I would like to gather more information about your environment to see if we can understand what might be causing this.

  1. Are you using a reverse proxy in front of Jira?
  2. Is there an out-bound proxy in your environment that might be necessary in order for the Jira server to make out bound network connections?
  3. Are you using Atlassian Crowd with Jira? 
  4. What address are you connecting to Jira on?
  5. I would also be interested to see if we can see what settings you have in the Jira Tomcat connector.  You can find this file in the $JIRAINSTALL/conf/server.xml  These settings inside the <Connector> tag will tell us more about the settings Jira is using to serve up its site that might be factor here.



Morning Andrew,

We use NAT'ing behind out firewall to access this instance of JIRA - Direct DMZ IP to External IP.

We are not using Atlassian Crowd is the site address

the server.xml is standard - SSL has been enabled

<Connector port="443" useBodyEncodingForURI="true" protocol="org.apache.coyote.http11.Http11Protocol" minSpareThreads="25" maxThreads="150" maxHttpHeaderSize="8192" enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000" acceptCount="100" sslProtocol="TLS" secure="true" scheme="https" maxSpareThreads="75" keystoreType="JKS" keystorePass="#############" keystoreFile="C:\SSLFile\oxfordcc_co_uk.jks" keyAlias="te-68f7ab32-b32d-4279-938b-44b84ba3e6bb" clientAuth="false" SSLEnabled="true"/>


Hi Damian,

I see three possible problems with this configuration and the information we have now.  

  1. You should not be able to use that specific protocol in Jira 7.3 or higher.   That protocol was deprecated by Tomcat in 8.5 versions which all Jira 7.3 and higher versions use.   More details on this in Jira 7.3 upgrade notes.
  2. Since the traffic to Jira has to pass through your firewall, I think that Jira/Tomcat need to have an additional parameter to tell the tomcat instance that this traffic is being redirected to it via this firewall. 
  3. Since it appears you are using Windows, there is another known bug that can cause this kind of HTTP 400 error on Windows based proxies in front of Jira, please see

    From that page:


    Due to the URL length increase, we are reaching the Windows Path Limit of 260 characters. This not the IIS URL limit. More details here:


    From the above articles, it is possible to modify the Windows Registry and increase the UrlSegmentMaxLength value to handle more characters:

    1. Backup the Registry
    2. With Regedit, browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
    3. Find the value for UrlSegmentMaxLength (or if it doesn't exist add a DWORD value), and change it to 00001000 (this is the hex for 4096)

    Powershell alternative:

    Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\HTTP\Parameters -Name UrlSegmentMaxLength -Value 4096

    After using either method to adjust the registry (Regedit or Powershell), you must restart Windows for the changes to take effect. This will necessitate downtime, please plan a maintenance window accordingly.

To address the first two possible problems, I changed the protocol here and I also added the proxyPort and proxyName parameters for this connector to look like so:

<Connector port="443" useBodyEncodingForURI="true" protocol="org.apache.coyote.http11.Http11NioProtocol" minSpareThreads="25" maxThreads="150" maxHttpHeaderSize="8192" enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000" acceptCount="100" sslProtocol="TLS" secure="true" scheme="https" maxSpareThreads="75" keystoreType="JKS" keystorePass="#############" keystoreFile="C:\SSLFile\oxfordcc_co_uk.jks" keyAlias="te-68f7ab32-b32d-4279-938b-44b84ba3e6bb" clientAuth="false" SSLEnabled="true" proxyName="" proxyPort="443"/>

(I tried to underline the changes/additions I made here)

I'm not sure if 443 is the correct proxyPort here, but I suspect it would be.  This would be the port number on which your firewall/reverse proxy is hosting the site on, not necessarily the port that Tomcat is opening up to serve content.

Also after you make this change to the server.xml file, you would need to save this file and then restart Jira in order for these changes to take effect.  I am interested to see if this might help prevent this 400 error.


Please let me know if you have any questions about these steps.



I have tried all the suggestions above, and I we still get the error (either internally / externally).  Interestingly if we access the site via a mobile phone, we do not get this error.


Kindest Regards

Hi @Damian Payne

That seems very strange.  Does the entire page fail to load with this HTTP 400 error?  Or does perhaps part of the page load up, with one or more elements showing a 400 error?

it might help if we could recreate this problem and then generating a HAR file to see what request is being made exactly and how the browser responds.  There are steps on how to do this depending on your browser in Generating HAR requests.

My other concern is to learn more about this firewall that exists between Jira and other connections.   It's strange that mobile devices would not have this problem, but other desktop clients continue to see this.   Could you let me know is this firewall a hardware device such as an F5, Cisco, Palo Alto, etc?   Or is the firewall a software service that sits on a Windows/linux server?   If this is a Windows box, then you might need to repeat those steps above in regards to the changes to the windows registry to allow these very long URLs to reach the Jira site.  I found a more comprehensive KB that explains this further in JIRA elements fail to render with HTTP 400 error.  I know you mentioned previously that the firewall is using NAT and that the Jira server is in the DMZ of this firewall zone, but I'm interested to learn more about your configuration to understand if perhaps there are alternative routes being taken for clients in different locations.

Also, does your server.xml have any other connectors?   I would actually suggest creating a 2nd connector for the sake of troubleshooting a problem like this.  Steps to do this are in How to bypass proxy and SSL setting to test network connectivity.   This can be helpful just to understand where this problem exists.  If using an unproxied connector, and we can't recreate this problem, then that tells us the problem is likely in regards to the way the firewall is re-routing traffic to Jira.   If that is the case, then we likely need to focus more on the details and configuration of the firewall itself.



The HAR file only showed 1 line (get command) - thus the page fails - not a component.  I admit its odd a mobile browser has no issue (even internally - emulated via chrome).  But externally (say over 4g) my browser on my pc will fail still with 400.  So its not an internal / external issue.

the firewall is a Barracuda X300 - (and to note we do have another instance of Jira (different version) that is running okay.  

We NAT the public IP to the DMZ IP - allow specific ports needed.  it then NATS to the internal DMZ IP  (his is the same as the other instance we use for something else).

Well then, let us try to focus on the differences between working and non-working devices.  

  1. Are the URLs the same between mobile and desktop devices for this logout URL?
  2. Have you been able to reproduce this every time on your desktop clients?  Or is it intermittent?
  3. Have you been able to repeat this 400 error in different browsers? (firefox, chrome, IE, Safari)
  4. Is the Jira site itself (the Tomcat site) being served up in a context path?   You can check this by looking at the server.xml file with the tag that looks like this:

    <Context path="" docBase="${catalina.home}/atlassian-jira" reloadable="false" useHttpOnly="true">

    I am curious here to learn if perhaps the site might be expecting a context path there.  You don't always need to do this, but some environments will do this when they want to have the Jira site appear in directory under the hostname/domain such as

Morning Andrew, 

To answer your questions.

1. yes the URLs (base domain url) are the same from either desktop client or mobile client. of course the mobile version has a different url after the domain /plugins/servlet/mobile#myjirahome.  From this site I can logout okay on my mobile over 4G.  

If I login on mobile device - and request the desktop site from the browser - It will error when I select logout (This page isn't working - Http Error 400).  I have also tried different browsers (Edge / IE / Firefox / Chrome) but all error or fail to load the page.

2. Every desktop I have tried causes this error to appear

3. as above - all browsers fail

4.  This is the context of the server.xml for the area you specify.


<Engine defaultHost="localhost" name="Catalina">

<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">


<Context docBase="${catalina.home}/atlassian-jira" path="" reloadable="false" useHttpOnly="true">


Just to say we have found the cause.  It was the url encoding with Tomcat version  , it did not like the | symbol in the URL.  So we applied a line into the file for tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}

Hi @Damian Payne

Thanks for posting back with the solution you found.  I am not familiar with this specific Tomcat property, but I was able to find this documented in their documentation on

In that document, it mentions that using that parameter could expose the system to a known vulnerability.  Please see for more details.


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

568 views 0 6
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you