Hi @nicoburgerhart, dank voor je bericht. Wij hebben de service niet recent gewijzigd. Aangezien de services ook naar behoren functioneren, lijkt het mij dat de fout in GeoWeb HTML5 viewer zit.
Zou je de fout die je krijgt wat explicieter kunnen omschrijven? Misschien dat iemand anders op het Geoforum de melding herkent.
Om deze service toe te voegen aan GeoWeb wordt daar een “Service Connection” voor gedefinieerd. Bij het testen van deze verbinding wordt een Connection Failed melding gegeven. De precieze oorzaak is niet uit logging af te leiden.
We zien dat probleem optreedt als aan de service URL de parameters request=GetCapabilities of service=WMS worden meegegeven, dan komt er niets meer terug.
Wellicht matcht er in de opzet van de service (capabilities XML) iets niet meer goed met Geoweb, echter dat is in tegenspraak met wat hierboven wordt aangegeven dat de service niet gewijzigd is.
Wij gaan het probleem aan de GeoWeb kant nog verder analyseren, maar wilden een wijziging aan de aanbodkant uitsluiten.
Een Connection Failed melding wordt ook gegeven bij niet overeenkomende TLS versies, maar dat lijkt het probleem niet te zijn (beide omgevingen TLS 1.2).
@nicoburgerhart geven jullie bij de configuratie alleen het endpoint .../wms? of ook nog de query parameters (request= & service=)
Ik weet niet hoe GeoWeb daar mee omgaat maar ik kan me voorstellen dat een dergelijk config andere requesten in de weg kan zitten (als er dus dan dubbele request= params gegenereerd worden)
M.a.w. kunnen jullie de config opgeven zonder query_params? Dus alleen https://geodata.nationaalgeoregister.nl/top10nlv2/wms?
Als je de Response-headers checkt van beide endpoints, dan zit daar toch nog best wel een verschil tussen. De Top10 lijkt gezipt te zijn, en geeft als Content-Type application/xml, terwijl de AAN als Content-Type text/xml geeft. Dat kan net het verschil maken tussen het wel kunnen parsen van de Capabilities.xml of niet.
@nicoburgerhart We hebben het zippen van oa de top10nlv2 capabilities nu uit gezet. Mogelijk zijn daarmee nu ook de problemen voor GeoWeb nu opgelost.
We hebben geconstateerd dat in sommige gevalllen dit inderdaad ploblemen oplevert. Graag hoor ik of het probleem zich nog steeds voordoet in GeoWeb
zo zwaar was het niet hoor Wouter! F12, get capabilities, vergelijk headers…
Met dit soort mysterieuze “bugs” kun je meestal wel aanwijzingen vinden in de headers van de requests, en dat bleek nu dus ook het geval, gelukkig. Dus ik check al heel snel even de headers, want dat helpt mijzelf ook heel regelmatig. Hoewel ik het wel verrassend vind dat Geoweb dus niet goed omgaat met gezipte http-responses - zelfs met javascript requests is mij dat nog nooit overkomen. Dat zippen en unzippen gebeurd meestal als onderdeel van 1 van de onderliggende protocollen (je ziet het bijvoorbeeld niet in de browser - enige clue daarvoor was die ETag).
zo zwaar was het niet hoor Wouter! F12, get capabilities, vergelijk headers… 
