"Loading" interstitial for reports

[RBecker]

My company runs a fairly large ViciDial installation that we are looking to move behind CloudFlare. All of our testing has been fine so far with the exception being reports. CloudFlare has a hard set request timeout of 100 seconds and it can't be changed (unless you're on a $40k+/yr enterprise plan). Because we have a very active system some of our reports take longer than that to execute and we end up getting a timeout before the report displays. Not sure how complex this would be but adding some sort of temporary "Loading..." display while the queries execute should solve that problem. I also think simply pre-loading the top bar at a minimum would be enough of an output for CF to think the webserver has responded, and is just waiting on the rest of the data. This is currently the only thing stopping us from moving over to CF fully. If any help is needed testing this please let me know and I would be happy to.

[mflorell]

Is the request timeout for PHP settings or is it in apache, or some other method?

[RBecker]

Apache and PHP aren't the issue, because the same reports ran without going through Cloudflare complete successfully. But once you click the SUBMIT button on a report, Cloudflare starts a 100 second timer in which it waits for a reply from the server. With the way reports currently render, Apache produces no reply to the client within that specified time, and Cloudflare throws an HTTP 524 error. That 100 second countdown is hard set by Cloudflare and can't be modified. Hence why I said some intermediate page displayed while the report loads should be sufficient and the report can appear in the same space the loading indicator was. Maybe similar to the lead loader that displays the load info then produces the BAD records on the page in real time as the load processes.

Alternatively, and possibly easier to do, would be to add a setting that lets you define an alternative hostname that reports pull from that is not proxied through Cloudflare. For example, our install runs on app.mycompany.com, and is what we want to protect with CF. If there was an "Alternate Report Execution URL" setting or similar, that could be set to reports.mycompany.com and does not proxy via CF. When the SUBMIT button is clicked on a report, the user would be redirected to reports.mycompany.com where the actual report executes.

[mflorell]

I'm sure we could figure out some kind of solution, but since we've never dealt with this before, and have no way to test a possible solution, it's probably not something we are going to implement on our own anytime soon.

[RBecker]

Thanks for the reply. I have a testing server that I'll do some poking around on, and if I can figure out some kind of solution I'll either follow up here or possibly submit a patch to Mantis for consideration.