Bad URL (Error 400) on Jaspersoft reports with lots of parameters?

[Rob-BBT]

We are having an issue with Jaspersoft reports that I hope someone else in the community may have experienced and resolved.    When we run Jaspersoft reports that have a lot of parameters, including the out of the box ones, when you click the Apply button, nothing happens and looking into the diagnostics on Chrome reveals that it is returning an Error 400 Bad URL.  

 

We have clustered environments that use IIS on the front end that use Siteminder for single sign on that then do an ISAPI redirect to the Clarity Tomcat servers.

 

We have followed recommendations to increase the URLSegmentMaxLength registry setting since by default JSON parameter legths are limited to 210.   We increased that to 1024.  

 

The weird thing is that it will run fine on one of the servers in the cluster but not all despite all servers being configured the same way.    So with 3 servers in our UAT cluster, 1 will run reports fine after the registry setting change but the other 2 will still throw a Bad URL error.

 

For reports that don't have a lot of parameters, the report runs fine on all servers, so it's definitely an issue with the size of the JSON parameters but we can't figure out why it works on only 1 of the servers in the cluster.

 

Anyone else see this and resolved it?

[Suman Pramanik]

Hi Robert,

 

If you have apache reverse proxy configured that can mask the error 400 codes. We did face this error and made the changes to the reverse proxy.

 

Regards

Suman Pramanik

[Abhijit Tarkunde]

Thanks Suman for the response!

We are using  Tomcat as an Application Server and IIS  as Web Server for Siteminder Agent.

In this context, would you please elaborate with few more steps how the above mentioned solution can be implemented.

 

Kind Regards,

Abhijit

[Suman Pramanik]

Hi Abhijit,

 

It tough to comment without detailed understanding of the network diagram, to find the blocking you can trace using some network tool like wireshark or fiddler and then see what is exactly blocking. In my case I had apache reverse proxy configured on top of PPM which was talking to site minder agent and there I have to turn off the proxy override to off in order to allow status code 400.

 

What basically it does is block the error and shows generic message to the user rather than exact message.

 

Hope this helps

 

Regards

Suman Pramanik

[Abhijit Tarkunde]

Hello Suman,

 

We do not want to block any error message.

 

We used fiddler trace and found that it is the length of combined parameters which reports like Missing Time generates  is blocking factor.

To fix it, we increased the length of UrlSegmentMaxLength on all the three servers in the Cluster.

 

As Rob already mentioned, it will run fine on one of the servers in the cluster but not all despite all servers being configured the same way.

So with 3 servers in our UAT cluster, 1 will run reports fine after the registry setting change but the other 2 will still throw a Bad URL error.

 

We want to fix this so that Users if redirected to any of these three servers, should be able to execute the report.

 

Already we have IIS server in front of Apache Tomcat. CA Siteminder does not have application agent for Apache Tomcat like they have for WebSphere.

Recommendation is to use IIS or Apache as WebServer, so that WebAgent can be deployed for Siteminder Authentication.

Hence not sure how Apache Reverse Proxy needs to be implemented here.

 

Kind Regards,

Abhijit

[Suman Pramanik]

Hi Abhijit,

 

I am not recommending any reverse proxy, I just shared my experience what I had seen with my reverse proxy implementation. When you do a fiddler or browser trace using F12 you will see a status code like 400. Take that URL and hit on the browser to see if it opens or block.

 

If it blocks then you need to see which application is blocking and take it from there

RegardsSuman Pramanik

[System]

Hi Abhijit_Clarity - Did SumanPramanik's response help answer your question? If so please mark as Correct Answer. Thanks!