cURL faalt bij ophalen bestemmingsplanteksten

cURL probleem bij ophalen html uit ruimtelijkeplannen.nl planregels.
In de diverse atom downloads, zoals enkelbestemmingen(.gml.gz) wordt verwezen naar html teksten op de site (kolom verwijzingnaartekst).
Ik wil deze bestanden downloaden in een programma om deze te scannen op bijv. bestemming specificatie. Dit geldt m.n. voor bestemminghoofdgroep maatschappelijk, maar dat terzijde.
Ik beschik over een cURL library die ik kan aanroepen vanuit mijn programma.
Dit is veel efficienter dan dezelfde taak uitvoeren met de betreffende executable (curl.exe of wget.exe)
Ik werk op een windows machine.
Als voorbeeld (met gebruik van de cURL executable):
curl -v --http2 -o dijkzicht.html ā€œDijkzigt: Regelsā€
Dit geeft problemen die ik deels heb opgelost door compilatie van cURL met extra functionaliteit.
Wat resteert is:
% Total % Received % Xferd Average Speed Time Time Time Current

  •                             Dload  Upload   Total   Spent    Left  Speed*
    
  • 0 0 0 0 0 0 0 0 --:ā€“:-- --:ā€“:-- --:ā€“:-- 0*
    ** Trying 145.77.103.94:443ā€¦*
    ** TCP_NODELAY set*
    ** Connected to ruimtelijkeplannen.nl (145.77.103.94) port 443 (#0)*
    ** ALPN, offering h2*
    ** ALPN, offering http/1.1*
    ** successfully set certificate verify locations:*
    ** CAfile: C:\Program Files\GDAL\curl-ca-bundle.crt*
  • CApath: none*
    } [5 bytes data]
    ** TLSv1.3 (OUT), TLS handshake, Client hello (1):*
    } [512 bytes data]
    ** TLSv1.3 (IN), TLS handshake, Server hello (2):*
    { [74 bytes data]
    ** TLSv1.2 (IN), TLS handshake, Certificate (11):*
    { [4750 bytes data]
    ** TLSv1.2 (IN), TLS handshake, Server key exchange (12):*
    { [333 bytes data]
    ** TLSv1.2 (IN), TLS handshake, Server finished (14):*
    { [4 bytes data]
    ** TLSv1.2 (OUT), TLS handshake, Client key exchange (16):*
    } [70 bytes data]
    ** TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):*
    } [1 bytes data]
    ** TLSv1.2 (OUT), TLS handshake, Finished (20):*
    } [16 bytes data]
    ** TLSv1.2 (IN), TLS handshake, Finished (20):*
    { [16 bytes data]
    ** SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384*
    ** ALPN, server did not agree to a protocol*
    ** Server certificate:*
    ** subject: C=NL; ST=Gelderland; L=Apeldoorn; O=Dienst voor het Kadaster en de openbare registers; CN=ruimtelijkeplannen.nl*
    ** start date: Mar 11 08:17:06 2022 GMT*
    ** expire date: Mar 11 08:27:00 2023 GMT*
    ** subjectAltName: host ā€œruimtelijkeplannen.nlā€ matched certā€™s ā€œruimtelijkeplannen.nlā€*
    ** issuer: C=BM; O=QuoVadis Limited; CN=QuoVadis Global SSL ICA G2*
    ** SSL certificate verify ok.*
    } [5 bytes data]
    > GET /documents/NL.IMRO.0599.BP1062Dijkzigt-va01/r_NL.IMRO.0599.BP1062Dijkzigt-va01.html HTTP/1.1
    > Host: ruimtelijkeplannen.nl
    > User-Agent: curl/7.66.0
    > Accept: /
    >
    { [5 bytes data]
    ** Mark bundle as not supporting multiuse*
    < HTTP/1.1 302 Found
    < Location: Dijkzigt: Regels
    < Connection: close
    <
    { [0 bytes data]
  • 0 0 0 0 0 0 0 0 --:ā€“:-- --:ā€“:-- --:ā€“:-- 0*
    ** Closing connection 0*
    } [5 bytes data]
    ** TLSv1.2 (OUT), TLS alert, close notify (256):*
    } [2 bytes data]

Er is een succesvolle handshake, maar ā€˜ALPN, server did not agree to a protocolā€™, wat mogelijk verklaart dat er geen data verzonden worden, ondanks dat het gevraagde bestand gevonden is, waarbij dan toch weer vermeld wordt dat dit via HTTP/1.1 gegaan is.
Bij een check mbv een andere download, andere site, wordt
** ALPN, server accepted to use h2*
gemeld.
De wget variant (voor genoemde ruimtelijkeplannen download) verloopt probleemloos.
De cURL executable specifiek beschikbaar gesteld voor windows faalt al bij de handshake.
Wget lijkt geen voldoende opties te hebben om alle verbindingsdetails weer te geven, zodat een vergelijk met de cURL perikelen niet gelukt is.
Ik heb gezocht naar een optie om een wget backend te vinden ā€“ niet eenvoudig (wel beschikbaar in python).
Daarom ā€“ uiteindelijk - de vraag of er misschien een verklaring te vinden is voor dit onverwacht problematische gedrag van cURL inzake de protocol acceptatie. Het maakt mij niet uit of dit HTTP /1.1 of HTTP/2 is of wellicht dat er nog iets anders nodig is voor de RPl site?

Je eerste vraag doe je naar https://ruimtelijkeplannen.nl.
Na een succesvolle handshake, krijg je als antwoord een HTTP 302 Found terug. HTTP 302 betekent dat de locatie van het bestand dat je zoekt tijdelijk elders te vinden is, en die locatie word teruggegeven in Location. Daar word je verwezen naar https://www.ruimtelijkeplannen.nl/ (let op de www!), maar het lijkt er op dat (jouw?) curl die 302-redirect niet volgt.

Althans, dat maak ik op uit de logging die je toont. Volgens mij heeft het niet te maken met protocol acceptatie.

1 like

Inderdaad zoals @sbjager zegt: curl ontvangt een 302 redirect naar nieuwe URL, die wordt niet automatisch gevolgd zoals bij wget.
Heel simpel, en doe dit altijd bij PDOK/Kadaster downloads: voeg -L (of
ā€“location, de Location optie, toe.
Zie ook: curl - How To Use

Dank jullie (Stefan, Just) voor de antwoorden. Ik heb dit over het hoofd gezien, mijn enige excuus is dat ik in de nog niet geupdate cURL wel -L heb geprobeerd, maar dit door andere problemen niet werkte.