Follow-up to #33 — now with the actual root cause, found using Grafida's own "Diagnose Connection" feature. Sharing in case the error handling can be improved.
Root cause (host-side, not Grafida): my host (o2switch) runs a WAF/rate-limiter ("Tiger Protect"). During connection, probeApiBase() fires its three candidate requests in quick succession, which tripped the rate limiter. All three candidates returned HTTP 429 with an HTML body (the WAF's page), not a Joomla response. Disabling the WAF fixed the connection instantly, confirming the API, token and endpoints were fine all along.
The Grafida-side observation: probeApiBase() seems to classify responses into three buckets — JSON:API success, 401/403 JSON, or network failure. An HTTP 429 with an HTML body matches none of these, so it falls through silently and the user only sees "Could not find a working Joomla Web Services API endpoint at this URL." That message points the user at the URL/endpoint, when the real cause is an upstream HTTP status the probe didn't surface.
Suggestion: when a candidate returns an unexpected HTTP status with a non-JSON body (429, 503, 5xx, or an HTML error page), surface the actual status code in the diagnostics — e.g. "server returned HTTP 429, likely a rate-limiter/WAF" — instead of the generic "endpoint not found". That single distinction would have pointed me at the host immediately.
Confirmed working on Grafida 0.2 once the WAF was adjusted. Thanks for the "Diagnose Connection" feature — it made the 429 visible and solved this in minutes.
Follow-up to #33 — now with the actual root cause, found using Grafida's own "Diagnose Connection" feature. Sharing in case the error handling can be improved.
Root cause (host-side, not Grafida): my host (o2switch) runs a WAF/rate-limiter ("Tiger Protect"). During connection, probeApiBase() fires its three candidate requests in quick succession, which tripped the rate limiter. All three candidates returned HTTP 429 with an HTML body (the WAF's page), not a Joomla response. Disabling the WAF fixed the connection instantly, confirming the API, token and endpoints were fine all along.
The Grafida-side observation: probeApiBase() seems to classify responses into three buckets — JSON:API success, 401/403 JSON, or network failure. An HTTP 429 with an HTML body matches none of these, so it falls through silently and the user only sees "Could not find a working Joomla Web Services API endpoint at this URL." That message points the user at the URL/endpoint, when the real cause is an upstream HTTP status the probe didn't surface.
Suggestion: when a candidate returns an unexpected HTTP status with a non-JSON body (429, 503, 5xx, or an HTML error page), surface the actual status code in the diagnostics — e.g. "server returned HTTP 429, likely a rate-limiter/WAF" — instead of the generic "endpoint not found". That single distinction would have pointed me at the host immediately.
Confirmed working on Grafida 0.2 once the WAF was adjusted. Thanks for the "Diagnose Connection" feature — it made the 429 visible and solved this in minutes.