BAG WFS bad request (sinds 20-02-2023)

Datasets BAG
#1

Hoi,

Sinds vanochtend geeft onze CI/CD een error op het bevragen van de BAG WFS v2_0 service.

Ik heb geen aankondigingen gezien over WFS maar misschien heb ik iets gemist?

De request ziet er als volgt uit:

    def get_bag_wfs_features_by_geometry(feature_type, coords, srs: "28992")
      query = <<-XML
      <Filter>
        <Intersects>
          <PropertyName>geometry</PropertyName>
          <gml:Polygon srsName="EPSG:#{srs}">
            <gml:exterior>
            <gml:LinearRing>
            <gml:posList>
            #{(coords + coords[0]).flatten.join(' ')} 
            </gml:posList>
            </gml:LinearRing>
            </gml:exterior>
          </gml:Polygon>
        </Intersects>
      </Filter>
      XML
      filter = URI.encode_www_form_component(query)
      base_url = "https://service.pdok.nl/lv/bag/wfs/v2_0?service=wfs&version=2.0.0&"
      response = HTTParty.get(base_url + [
        "request=getfeature",
        "typenames=#{feature_type}",
        "filter=#{filter}",
        "outputFormat=application/json"
      ].join('&'))

      raise PdokRequestError.new(response) unless response.success?

      JSON.parse(response.body)["features"]
    end

Zit hier iets geks in dat niet meer wordt ondersteund?

#2

Je vraag is zo nogal zonder context, dus ik heb in ieder geval twee vragen terug voor je:

  • Wat is de error die je terug krijgt?
  • Wat zijn de waardes van de diverse variabelen?
  • Deze code heeft wel gewerkt?

We kunnen zo niet zien wat er daadwerkelijk op de BAG WFS word afgevuurd, dus reproduceren is dan wat lastig…

#3

Hoi @sbjager , sorry ik dacht dat er misschien iets veranderd was aan de service. Hier is wat uitgebreidere info:

De error die ik terugkrijg:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>400 Bad Request</title>
</head>
<body>
  <h1>400 Bad Request</h1>
</body>
</html>

De bounds:

      bounds = [
        [124817.95,489494.68],
        [124838.74,489495.47],
        [124836.99,489481.08],
        [124819.87,489485.07]
      ]

De srs: 28992

De filter XML:

<Filter>
  <Intersects>
    <PropertyName>geometry</PropertyName>
    <gml:Polygon srsName="EPSG:28992">
      <gml:exterior>
      <gml:LinearRing>
      <gml:posList>
      124817.95 489494.68 124838.74 489495.47 124836.99 489481.08 124819.87 489485.07 124817.95 489494.68 
      </gml:posList>
      </gml:LinearRing>
      </gml:exterior>
    </gml:Polygon>
  </Intersects>
</Filter>

En een gehele log van de request:

opening connection to service.pdok.nl:443...
opened
starting SSL for service.pdok.nl:443...
SSL established, protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384
<- "GET /lv/bag/wfs/v2_0?service=wfs&version=2.0.0&request=getfeature&typenames=pand&filter=++++++%3CFilter%3E%0A++++++++%3CIntersects%3E%0A++++++++++%3CPropertyName%3Egeometry%3C%2FPropertyName%3E%0A++++++++++%3Cgml%3APolygon+srsName%3D%22EPSG%3A28992%22%3E%0A++++++++++++%3Cgml%3Aexterior%3E%0A++++++++++++%3Cgml%3ALinearRing%3E%0A++++++++++++%3Cgml%3AposList%3E%0A++++++++++++124817.95+489494.68+124838.74+489495.47+124836.99+489481.08+124819.87+489485.07+124817.95+489494.68+%0A++++++++++++%3C%2Fgml%3AposList%3E%0A++++++++++++%3C%2Fgml%3ALinearRing%3E%0A++++++++++++%3C%2Fgml%3Aexterior%3E%0A++++++++++%3C%2Fgml%3APolygon%3E%0A++++++++%3C%2FIntersects%3E%0A++++++%3C%2FFilter%3E%0A&outputFormat=application/json HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: */*\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: service.pdok.nl\r\n\r\n"
-> "HTTP/1.1 400 Bad Request\r\n"
-> "Access-Control-Allow-Headers: Content-Type\r\n"
-> "Access-Control-Allow-Method: GET, POST, OPTIONS\r\n"
-> "Access-Control-Allow-Origin: *\r\n"
-> "Content-Length: 345\r\n"
-> "Content-Type: text/html\r\n"
-> "Date: Mon, 20 Feb 2023 17:19:18 GMT\r\n"
-> "Connection: close\r\n"
-> "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload\r\n"
-> "\r\n"
reading 345 bytes...
-> "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n         \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\" lang=\"en\">\n <head>\n  <title>400 Bad Request</title>\n </head>\n <body>\n  <h1>400 Bad Request</h1>\n </body>\n</html>\n"
read 345 bytes
Conn close

Ik hoop dat jullie er wat aan hebben :slight_smile:

edit: oh ja en je laatste vraag, deze code werkte afgelopen week nog, onderdeel van onze test suite is exact deze request. Hij zit ook in ons product verwerkt, maar die feature wordt niet elke dag gebruikt en ik heb er nog geen klacht over gehad.

#4

Ik weet niet welk stukje code je url codeert, maar de spaties die worden omgezet in plus-tekens en de harde returns doen je request geen goed. Als ik uit jouw stukje code de url pak, daar alle plus-tekens uit haal, en alle harde returns ook, dan krijg ik gewoon een antwoord, in geojson dat 3 panden bevat.

Dit is waar het op stuk loopt. En dat ligt niet aan de server…

#5

Vandaag is er een wijziging uitgerold voor al onze WFS services, die als bijeffect heeft dat er stricter wordt gevalideerd op de content van url parameters. Met name de new line %0A mag met deze wijziging niet meer. Aangezien dit bijeffect niet was voorzien en meer gebruikers problemen ervaren ga ik de wijziging voor nu terugdraaien. Uiteraard is het altijd een goed idee om de request schoon te houden.

3 likes
#6

Zeker in een GET-request zou ik altijd alle whitespace er uit halen… kan me ook niet (meer) herinneren dat spaties omgezet werden naar ±tekens, dat vind ik ook wel een rare. %20 wel, maar een +? da’s volgens mij nog uit de Netscape tijd (waarmee ik meteen mijn leeftijd weggeef :rofl:)

1 like
#7

Handig om zo’n wijziging hier aan te kondigen? :slight_smile:

#8

Eens, daarom stond er in mijn get request ook geen whitespace meer, alles was netjes ge-urlencode. Dat spaties met + zijn ge-encode vind ik ook een beetje frappant. Ik heb een beetje research gedaan en ik vind het op zich wel acceptabel om dat niet toe te staan, ik houdt ook niet van archaische de facto protocollen, ik vind het naar dat de library dat zo doet als het slecht gestandardiseerd is. Het staat wel mooi en het scheelt wat bytes in de toch wel lompe query params.

%0A blokkeren vind ik wel echt een slecht idee. Dat is gewoon netjes een url encoded newline, en in jullie API accepteren jullie XML en in XML horen newlines, en spaties of tabs voor indentatie. Dat blokkeren zou van de zotte zijn naar mijn idee.

Als jullie geen XML in de query params willen zou ik dat ook prima vinden, maar dat is wel een serieuze API wijziging die dan goed gecommuniceerd moet worden.

#10

Het upgraden van componenten is een continu proces. Als we impact voor gebruikers voorzien, zullen we altijd een nieuwe versie van de API releasen om gebruikers de kans te geven hun software daarop aan te passen. Dit specifieke scenario was bij het testen onopgemerkt gebleven.

#11

Het blokkeren van %0A in GET requesten was onbedoeld en werd veroorzaakt door het upgraden van een proxy server. We zijn niet voornemens om dit voor GET requesten naar een WFS service in de toekomst te blokkeren.