Icinga
[dev.icinga.com #7360] URL too long if selecting too many services/hosts
This issue has been migrated from Redmine: https://dev.icinga.com/issues/7360
Created by Foxeronie on 2014-10-08 20:28:36 +00:00
Assignee: (none) Status: New Target Version: Backlog Last Update: 2016-01-12 14:53:51 +00:00 (in Redmine)
Hi,
I get a "Request-URI Too Long" if I select too many services with shift.
Best regards, Patrick
Attachments
- iw2_uri.jpg Foxeronie - 2014-10-08 20:27:53 +00:00 - error
Updated by tgelf on 2014-11-11 22:55:49 +00:00
I manually selected more than 50 services without such issue, but of course everybody sooner or later will be able to encounter "Request-URI Too Long". I'd suggest to add some kind of a "continue with filtered list" selector. That would cut the link down to the filter length and allow one to handle a massive amount of objects at once.
Best, Thomas
Updated by tgelf on 2014-11-14 16:28:40 +00:00
In addition to the proposed workaround I'd like to suggest the following behaviour on 414 Request-URI Too Long
- re-send the same request as specially crafted POST
- transform such "special" requests back to a fake GET on server side
- fake the browser location using the history API, it should show something like /url-has-been-shortened
- store the originally desired link or fake POST data also in the history
- respect that information when navigating the history
That way we could preserve browser-based forth/back navigation. We would be able to send "too-long-links" in a backward-compatible way without breaking server-side stuff. We would have no hard-coded URL length limit (we should also check browser limits of course), servers accepting longer URLs would be served such.
When the user then doesn't pay attention and bookmarks or mails the current link to someone, /url-has-been-shortened would show a friendly error message stating that the link you're trying to open was not portable.
Cheers, Thomas
Updated by elippmann on 2015-03-31 09:36:57 +00:00
- Subject changed from Request-URI Too Long if selecting too many services/hosts to URL too long if selecting too many services/hosts
- Category set to Framework
- Target Version set to 2.0.0-rc1
Updated by elippmann on 2015-05-27 07:09:05 +00:00
- Target Version changed from 2.0.0-rc1 to Backlog
Updated by CostinGament on 2016-01-12 14:53:51 +00:00
Hello all,
I am one of the Atlas experiment's sysadmins at CERN and we've recently switched to Icinga2. Unfortunately, the bug described in this ticket is still very much alive and it's preventing us from completely going the way of icinga-web2. For now, we're relying on the old web interface as a backup, but this can't go on for long.
Do you have any updates about fixing this bug, is it in your current plan?
Thank you, Costin
8kB are already enough most of the time. The cases where it isn't do not justify requiring a configuration change as the final solution.
Just run into the same issue when trying to trigger a check now for ~800 services. Are there any plans to fix this? Apparently this bug report is almost 5 years old!
@mphilipps Using Check Now for 800 services. :open_mouth: I'd say this bug is still open because of exactly such edge cases. You better want to wait for Icinga 2 to schedule the checks by itself instead of forcing such an enormous amount. And even if you have to, consider doing this by connecting to Icinga's API directly. There are no immediate plans to fix this, though we are aware of it and will make sure it doesn't affect the monitoring module's next evolution.
I'am running into this, by just selecting 12 Checks on 6 different Servers to acknowledge the serviceproblem.
Edit: The tip from @Al2Klimov IS helping (LimitRequestLine 10000), as soon as I disabled some hardening of the apache2 server as some security policies want 512 bytes only :)
The same happens when you click on a column header (hostname) of a service grid containing a lot of services.
@nilmerg There is the bulk processing button now. This kinda handles it :-)
