@jampukka yes, correct. GHC was upgraded with OWSLib 0.20.0 which introduced extended OAFeat support, especially requesting the OpenAPI JSON Doc. The Probes for OAFeat were rewritten to that. More strict checking towards the standard. For example pygeoapi (https://demo.pygeoapi.io/master) passes all Probe checks.
This is the landing page for my service https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/
Maybe OWSLib Features#api() returns something else than json?
Looking at: https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/api which looks ok. GHC OAFeat Probe also use HTTP Content Negotiation now.
So sending
Accept: application/json, looks like some implementations don't like that...
So maybe it doesn't like that
I'll have to check
So maybe the solution is that GHC OAFeat Probe also adds
application/vnd.oai.openapi+json; version=3. to Accept headers.
That doesn't even make sense, I'll have to fix that
Though this works as well offcourse:
curl "https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/api" -H "Accept: application/json, application/vnd.oai.openapi+json; version=3.0"
Ok, thanks, was encountering more similar situations (return code 406) in GHC demo, e.g. https://www.ldproxy.nrw.de/kataster/collections?f=json where items can be requested as
application/geo+json.
or
application/gml+xml;profile=\\\"http: //www.opengis.net/def/profile/ogc/2.0/gml-sf2\\\";version=3.2" , try to get that right...
curl "https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/selite/items" -H "Accept: application/json"
{
"code" : "500",
"description" : "HTTP 406 Not Acceptable"
}
Yea that doesn't work either
application/geo+json does work, and not setting any Accept header works and the service defaults the Content-Type to application/geo+json
Probably best to change that also so people can use the service with OWSLib
Yes GHC OAFeat probe sets the HTTP Headers, fixed now to
"Accept: application/json", but maybe this is a direction with many interworking issues (over f=json).
Or the headers should be derived from the endpoint's metadata.
Does OWSLib Features client work with anything else than JSON?
e.g. it requires the server to support conformance class http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/geojson which sets some requirements (http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_conformance_class_geojson)
with the headers from the constructor.
But I need to first solve some Docker build issues for GHC (demo). OWSLib issues: best discussed on https://gitter.im/geopython/OWSLib
So Content Negotiation it will be. Will adapt GHC OAFeat Probe to send proper
Accept: headers via issue #313 .
@jampukka https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/ now passes all OAFeat Probes after #338.
GeoHealthCheck 0.8.3 is out. See the release info for what went in. Highlights: making GHC outgoing HTTP more web-friendly with
User-Agent and compression Accept. Upgraded OWSLib to 0.20.0 (now WFS auth should work) and enhanced OGC OAFeat Probe support. German translation patches contributed by @astroidex.
Hi all, I am completely new user of GeoHealthChcek and I have deployed GHC as Docker container with default settings, tried to add one WMS and except first request, it doesn’t send any, even I set to run every 10 minutes. I suppose that I had to do more than default setting, right? Thx for any response.
Just a quick question on the, GeoHealthCheck.plugins.check.checks.HttpStatusNoError ...The check itself is a test if the HTTP status code is in the 400 or 500-range... does that mean that if the service has some authentication, the test would fail on the challenge response (401 unauthorized), or only if the authentication failed
@MiroslavHrcan yes you gave the answer already in your last sentence: you have to set the env var:
GHC_RUNNER_IN_WEBAPP=True. The default for Docker is False. There has been some discussion and an issue around this: #303. We are a bit cautious to change this default as it may silently affect existing installs. Especially in a Docker deployment it is good practice to separate the 3 main GHC components (UI, Healthcheck Runner and database). docker-compose is a convenient way, see this example.
@nmtoken no definitive answer. This is a broad
Check. You could write a Check Plugin for a specific 401-Check. Out of my head: the Run report would specify the specific HTTP-error code. I think both your options apply: AFAIK in HTTP (Basic, Token) Authentication is a one-time request/response: if there are no auth-headers or if the auth-headers contain the wrong credentials, a 401 response is returned. GHC supports two Auth methods: Basic and Bearer Token per Resource (endpoint) which can be configured in the UI and will be sent with each HTTP-request in the HTTP headers.