You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see some similar problems but always related to self hosted proxies, not external (unmanaged) ones.
My proposal is to implement a waiting page with http status code 102 so the client knows something is taking some time to process: https://http.dev/102
With this addition there'll be no need to increase max_execution_time. This is used in other projects that generate reports.
The text was updated successfully, but these errors were encountered:
In GLPI 11.0, we introduced a system that could be used to prevent timeouts on such long operations. It is only used for the installation process (see #18296), but we planned to use it for the update process too, for the massive actions, and I guess we should also use it for the export operations.
Code of Conduct
Is there an existing issue for this?
Version
10.0.10
Bug description
When performing a large export (csv, pdf, slk) I get timeouts from cloudflare (probably happens the same with similar products).
The problem is similar to apache/php timeouts (max_execution_time + memory_limit) but with an external proxy, so I can't configure or modify anything.
If I circumvent cloudflare and I access the server directly (internal IP) I get the export without any problem.
Relevant log output
Page URL
http://localhost:5870/glpi10/front/ticket.php?is_deleted=0&as_map=0&browse=0&criteria%5B0%5D%5Blink%5D=AND&criteria%5B0%5D%5Bfield%5D=16&criteria%5B0%5D%5Bsearchtype%5D=morethan&_select_criteria%5B0%5D%5Bvalue%5D=0&criteria%5B0%5D%5Bvalue%5D=2024-01-01%2012%3A05%3A49&itemtype=Ticket&start=0&_glpi_csrf_token=683b2a04d6a87b3f0267f15746ce9c384cc5cf7baf6ae6da4c8f14677a498434&sort%5B%5D=19&order%5B%5D=DESC
This URL is using a tunnel to the web server.
Steps To reproduce
No response
Your GLPI setup information
No response
Anything else?
I can see some similar problems but always related to self hosted proxies, not external (unmanaged) ones.
My proposal is to implement a waiting page with http status code 102 so the client knows something is taking some time to process: https://http.dev/102
With this addition there'll be no need to increase max_execution_time. This is used in other projects that generate reports.
The text was updated successfully, but these errors were encountered: