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?