Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 11 10:48
    justb4 commented #328
  • Nov 11 09:03
    nmtoken commented #328
  • Nov 10 21:37
    justb4 commented #328
  • Nov 10 18:02
    nmtoken commented #328
  • Nov 10 17:10
    nmtoken commented #328
  • Nov 05 16:31
    petermozolik closed #344
  • Nov 05 16:31
    petermozolik commented #344
  • Nov 05 12:17
    justb4 commented #344
  • Nov 05 12:06
    justb4 commented #344
  • Nov 05 12:05
    justb4 commented #344
  • Nov 05 11:18
    petermozolik labeled #344
  • Nov 05 11:18
    petermozolik opened #344
  • Nov 04 08:13
  • Nov 03 14:09

    justb4 on 0.8.1

    (compare)

  • Nov 03 14:09

    justb4 on 0.8.2

    (compare)

  • Nov 03 14:05

    justb4 on 0.8.3

    (compare)

  • Nov 03 14:03

    justb4 on master

    Bump to v0.8.3 with Py3 string … (compare)

  • Nov 03 13:47

    justb4 on master

    quickfix for string decoding ba… (compare)

  • Nov 03 12:54

    justb4 on master

    quickfix for string encoding ba… (compare)

Just van den Broecke
@justb4
@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.
Janne Heikkilä
@jampukka
Just van den Broecke
@justb4

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...
Janne Heikkilä
@jampukka
yea my /api is only available as application/vnd.oai.openapi+json; version=3.0
So maybe it doesn't like that
I'll have to check
Just van den Broecke
@justb4
Yes, correct: see
image.png
So maybe the solution is that GHC OAFeat Probe also adds application/vnd.oai.openapi+json; version=3. to Accept headers.
Janne Heikkilä
@jampukka
curl "https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/api" -H "Accept: application/json" { "code" : "500", "description" : "HTTP 406 Not Acceptable" }
That doesn't even make sense, I'll have to fix that
Just van den Broecke
@justb4
This is more a discussion for the WFS_FES Gitter Channel. Need to dive into the standard.
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"
Janne Heikkilä
@jampukka
Thanks, I'll fix mine to be a bit more lenient so it accepts both
Just van den Broecke
@justb4
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...
Janne Heikkilä
@jampukka
maybe OWSLib should also be changed to Accept both, if it's searching for link with rel: service-desc and type: application/vnd.oai.openapi+json;version=3.0 then it would be logical to Accept: application/vnd.oai.openapi+json;version=3.0, right?
Just van den Broecke
@justb4
Yes, probably, I don't think OWSLib does HTTP content negotiation. It does look for service-desc. But yes, makes sense.
Janne Heikkilä
@jampukka
Oh okay. I'll fix mine anyways
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
Just van den Broecke
@justb4
OWSLib looks for service-desc and type='application/vnd.oai.openapi+json;version=3.0' in landing page to get OpenAPI doc url, but does not use HTTP Content neg.
Janne Heikkilä
@jampukka
So it's the GHC OAFeat probe that does it?
Just van den Broecke
@justb4
Users of OWSLib now can add headers, but only in the constructor of oafeat client. My first try was with ?f=json, but got into path issues with OWSLib, maybe a bug, so switched to HTTP COntent neg.
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.
Janne Heikkilä
@jampukka
I see it passes the headers to the constructor
Just van den Broecke
@justb4
Yes, so it is hard to change per-request.
Janne Heikkilä
@jampukka
But it's simple for Basic Auth for example
Does OWSLib Features client work with anything else than JSON?
Just van den Broecke
@justb4
Does not seem so: single _request() function: return response.json()
with the headers from the constructor.
Janne Heikkilä
@jampukka
yeah not trivial to change that
Just van den Broecke
@justb4
But I need to first solve some Docker build issues for GHC (demo). OWSLib issues: best discussed on https://gitter.im/geopython/OWSLib
Janne Heikkilä
@jampukka
Thanks I'll join there
Just van den Broecke
@justb4
Just van den Broecke
@justb4
So Content Negotiation it will be. Will adapt GHC OAFeat Probe to send proper Accept: headers via issue #313 .
Just van den Broecke
@justb4
Upcoming Content Negotiation OAFeat Probe: geopython/GeoHealthCheck#338 ..
Just van den Broecke
@justb4
Janne Heikkilä
@jampukka
great, thanks!
Just van den Broecke
@justb4
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.
Astrid Emde
@astroidex
Congratulation to the release of GeoHealthCheck 0.8.3
MiroslavHrcan
@MiroslavHrcan
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.
James Passmore
@nmtoken
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
Just van den Broecke
@justb4
@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.
Just van den Broecke
@justb4
@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.