400 Bad Request when creating new sprint

[Bartek Żółkiewski]

Hi,

lately we started proxying our Jira instance using Apache and we noticed an error, when trying to create a new sprint. It says "error bad request".

Here is a screenshot from chrome

And here is Tomcat config

<Connector port="8181" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false" scheme="http"
proxyName="<ourdomain>.eu" proxyPort="443"/>

I tried adding a certificate to jre cacerts - not helping.
Do you have any idea how to fix it? Google says nothing relevant and I've been fighting with this problem for 2 days straight now.

[Andy Heinzer · Accepted solution]

Well your scheme parameter in Jira's server.xml should be https not http since that connector is clearly being used to allow traffic in from a proxy using SSL on port 443 to reach the Jira site.

If changing that and restarting Jira does not help, please try to recreate the problem and then click into the Response tab in the browser console.   I'd be interested to see more details about why this request is failing, and that response might tell us more.

Also I'm interested to learn the full request URL, the Origin, and referer.  Depending on the values listed in each of these might be able to tell us more about this problem.

Did you follow the steps in Integrating Jira with Apache using SSL?

[Bartek Żółkiewski]

Hi, 

first of all - thank you for a quick response.
I changed the scheme in server.xml as you said to https, but unfortunately, it didn't help.
I also double-checked my configuration with the tutorial you linked - it seems like everything should work fine. Here are two screenshots you asked for - with a Response, Request URL, Origin, and Referer.


When accessing through the second connector, everything works like a charm.

[Andy Heinzer]

So those look good.  I was afraid that the referer and origin URLs were different.  In which case, you could encounter a cross site scripting protection explained in https://confluence.atlassian.com/kb/cross-site-request-forgery-csrf-protection-changes-in-atlassian-rest-779294918.html

But I don't think you are actually seeing that problem with the information I can see so far.  Instead I want to know more about your Apache configuration here.   I would expect that you followed the steps in Integrating Jira with Apache using SSL in regards to how Apache is configured to act like a proxy for jira.  This guide explains how we expect both Jira and Apache to be configured in order to work together in this configuration.

The fact that everything works though another connector in Jira that likely bypasses this proxy makes me think the problem is in regards to the way that apache is configured.

[Bartek Żółkiewski]

Here is an http to https configuration and here is the proxy configuration.

[Andy Heinzer]

Hi Bartek,

I can see that your webrequest seems to be using a text encoding of ISO-8859-1.  However in my Jira instance, I have an character encoding of UTF-8.  I'm not sure this is directly related, but this is only difference I can see so far that might be a factor in this problem.   It might be worth walking through JIRA Application internationalisation and encoding troubleshooting just to make sure that Jira is set to use UTF-8 everywhere.  

Could we also gather a HAR file from you where you reproduce this error?  Steps on how to do this are in Generating HAR files and analyzing web requests.  I am hopeful that this information will tell us more about the request, the content, the headers, etc.  With all of this together I should be better able to tell what is causing this HTTP 400 error.

Is this problem only happening when trying to create a sprint?  Are you able to have this Jira site create new issues, transition issues, and edit Jira issues?   I am just trying to understand how far this problem extends on this site.

Thanks

Andy

[Bartek Żółkiewski]

Hi,

like you said I followed steps in JIRA Application internationalisation and encoding troubleshooting, unfortunately, it didn't help.

Here is the HAR file: https://puu.sh/AsG3g/c4c2e240ab.har

As you can see, there are more requests failing. For example remindlater or summary.

[Andy Heinzer]

Hi Bartek,

I am stumped.  I can't see any clear problems with your configuration.  Since this works on another connector that does not use apache, I believe that there is something in your network or in Apache's configuration that is altering either the payload (json request), a cookie, or some other header before it reaches the Jira site which causes this bad request error.

Try taking a look at https://stackoverflow.com/questions/10309751/bad-request-your-browser-sent-a-request-that-this-server-could-not-understand

There are suggestions to clear your cookies in your client, but I'm doubtful that will resolve this.   Another post in that thread suggested the use of the apache logging in order to try to diagnose the problem further.  Perhaps we can see more information from the apache logs when this happens in order to better understand why this is happening.

[Bartek Żółkiewski]

Hi Andrew,

as you said, I took a look at apache logs and here is what I found:

[Mon May 28 10:15:50.131748 2018] [:error] [pid 73508] [client 50.0.0.254] ModSecurity: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "/etc/modsecurity/modsecurity.conf"] [line "62"] [id "200002"] [msg "Failed to parse request body."] [data "JSON parser error: parse error: premature EOF\\x0a"] [severity "CRITICAL"] [hostname "jira.integree.eu"] [uri "/rest/internal/1.0/licensebanner/remindlater"] [unique_id "Wwu6tn8AAQEAAR8kRYwAAAAC"]

This seems to be the problem. It is a problem with mod_security having a problem with POST requests with an empty body.

The solution is here: https://stackoverflow.com/questions/38257534/mod-security-a-rule-to-allow-post-requests-without-a-request-body

Thank you for your help :)

[Andy Heinzer]

@Bartek Żółkiewski Thanks for posting back with the details of the solution you found!  That was the missing piece.