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.
Hi,
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 catalina.properties file for tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
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 https://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html
In that document, it mentions that using that parameter could expose the system to a known vulnerability. Please see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816 for more details.
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Morning,
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well then, let us try to focus on the differences between working and non-working devices.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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">
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Morning,
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
https://mddjira.oxfordcc.co.uk 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"/>
</Service>
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Damian,
I see three possible problems with this configuration and the information we have now.
From that page:
Cause
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:
- https://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath
- https://social.msdn.microsoft.com/Forums/en-US/723e6bfd-cab7-417b-b487-67f1dcfa524f/uri-path-great-than-260-characters-yeilds-bad-request?forum=netfxnetcom
Workaround
From the above articles, it is possible to modify the Windows Registry and increase the UrlSegmentMaxLength value to handle more characters:
- Backup the Registry
- With Regedit, browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
- 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="mddjira.oxfordcc.co.uk" 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.
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Regards,
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.