In mijn applicaties voor AutoCAD vraag ik via de API gebieden op van de BGT en Kadastrale kaart. De API retourneerde tot gisteren altijd een HttpStatusCode ‘Accepted’ (response 202) en vandaag is dat ineens een ‘OK’ (response 200) geworden.
De API documentatie spreekt nog steeds van 202, niet van 200.
Is dit gewijzigd? En zo ja, waarom?
@Jeroen_PDOK of @wouter.visscher of iemand anders van de PDOK die hier iets van kan zeggen?
Ik heb het even geprobeerd, maar ik krijg nog steeds een 202 response terug. Zie voorbeeld:
Request:
curl -iX 'POST' \
'https://api.pdok.nl/lv/bgt/download/v1_0/full/custom' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"featuretypes": [
"bak",
"gebouwinstallatie",
"kunstwerkdeel",
"onbegroeidterreindeel"
],
"format": "citygml",
"geofilter": "POLYGON((211417.92 475752.4800000001,212390.64000000004 475896.12,212916.48000000004 475818.84,212879.52000000005 475360.2,212950.08000000002 475203.12,212839.2 475065.36,212819.04 474981.36,212819.04 474877.2,212772 474857.04,212792.16 474769.68,212832.48 474705.84,212889.6 474695.76,213010.56000000003 474685.68,213044.16 474611.76,213030.72 474450.48,212637.6 474423.6,212708.16 473956.56,211122.24000000002 473849.04,210453.6 473896.08,210315.84000000003 473970,211417.92 475752.4800000001))"
}'
Response:
HTTP/1.1 202 Accepted
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Method: GET,POST,OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 169
Content-Type: application/json
Date: Wed, 31 May 2023 07:40:26 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
{"_links":{"status":{"href":"/lv/bgt/download/v1_0/full/custom/79f0efbb-3051-475b-4e3d-dd6080aece77/status"}},"downloadRequestId":"79f0efbb-3051-475b-4e3d-dd6080aece77"}
Zou je een voorbeeld kunnen sturen van de request die je doet?
Vanuit de code:
De Key hoort Accepted te zijn maar is ineens een OK.
De request is goed en krijg ook resultaat terug (status en download link) maar geen 202:
We zijn er naar aan het kijken. We zien in onze logging dat we sinds gisteren op dit request 202 Accepted en 200 OK reponses teruggeven, terwijl dit alleen 202 Accepted reponses horen te zijn. Bij onze testen komen er uitsluitend 202 responses uit. Is het mogelijk om de exacte request te sturen inclusief headers?
Kan dit niet in curl format aangeven, alleen de eigenschappen van het request object in de code.
Headers: er worden twee ingesteld, namelijk ‘accept’ en ‘User-Agent’.
accept: application/json
User-Agent: Other
Die laatste moet ingesteld zijn vanwege SSL protocol.
De JSON content is dit:
"{\"featuretypes\":[\"bak\",\"begroeidterreindeel\",\"bord\",\"gebouwinstallatie\",\"installatie\",\"kast\",\"kunstwerkdeel\",\"mast\",\"onbegroeidterreindeel\",\"ondersteunendwaterdeel\",\"ondersteunendwegdeel\",\"openbareruimtelabel\",\"overbruggingsdeel\",\"overigbouwwerk\",\"overigescheiding\",\"paal\",\"pand\",\"put\",\"scheiding\",\"sensor\",\"spoor\",\"straatmeubilair\",\"tunneldeel\",\"vegetatieobject\",\"waterdeel\",\"waterinrichtingselement\",\"wegdeel\",\"weginrichtingselement\"],\"format\":\"citygml\",\"geofilter\":\"POLYGON((190506.296 490296.209,190024.261 490103.373,190267.660 489561.676,190885.851 489917.264,190506.296 490296.209))\"}"
Het resultaat wat terug komt is dit:
Headers:
{StatusCode: 200, ReasonPhrase: 'OK', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Wed, 31 May 2023 07:53:20 GMT
Content-Length: 169
Content-Type: application/json
}}
Result:
{[OK, {"_links":{"status":{"href":"/lv/bgt/download/v1_0/full/custom/9f282837-2ef1-4aa5-599d-fe533dbec119/status"}},"downloadRequestId":"9f282837-2ef1-4aa5-599d-fe533dbec119"}]}
is hier al wat meer over duidelijk? wij lopen hier tegen hetzelfde probleem aan namelijk
Kun je wellicht het volledige request capturen met zoiets als Fiddler | Web Debugging Proxy and Troubleshooting Solutions?
@Anton bedankt voor de input. We zijn nog bezig met dit issue. Inmiddels werkt het wel weer, dit komt doordat we de security wijzigingen van gisteren hebben teruggedraaid. De exacte oorzaak is nog onbekend. Aangezien het hier security wijzigingen betreft willen we deze situatie niet te lang laten duren.
We hebben de code zoals die in InfraCAD wordt gebruikt in dotnet nagemaakt, ook dan krijgen we gewoon een 202 response. We hebben inmiddels zelf een trial versie van infracad die we kunnen gebruiken om te onderzoeken hoe de requesten er low level uitzien. Vermoedelijk zit er iets in de request wat bij ons een issue triggerd.
Hm, even kijken, ik kan niet de request zelf inzien. Wel dit:
Request (Raw):
CONNECT api.pdok.nl:443 HTTP/1.1
User-Agent: Other
Host: api.pdok.nl
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 64 77 43 AA 7C 14 72 DF 16 74 00 02 30 0B A8 F7 0A A6 35 AE B8 E5 AF 1C 59 B4 0D 02 60 7F E5 54
"Time": 08-07-2060 23:36:36
SessionID: 79 3A 00 00 F8 42 CC F5 5C B6 E6 62 A0 FC 94 04 5E B0 67 C1 B1 B8 B4 16 E9 18 A6 D0 AE E4 C0 AF
Extensions:
server_name api.pdok.nl
supported_groups x25519 [0x1d], secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algs rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha1, ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_sha1, dsa_sha1, rsa_pkcs1_sha512, ecdsa_secp521r1_sha512
SessionTicket empty
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[009D] TLS_RSA_WITH_AES_256_GCM_SHA384
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
Compression:
[00] NO_COMPRESSION
Response (Raw):
HTTP/1.1 200 Connection Established
FiddlerGateway: Direct
StartTime: 14:55:06.216
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls12
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
== Server Certificate ==========
[Version]
V3
[Subject]
CN=*.pdok.nl, O=Dienst voor het Kadaster en de openbare registers, L=Apeldoorn, S=Gelderland, C=NL
Simple Name: *.pdok.nl
DNS Name: *.pdok.nl
[Issuer]
CN=QuoVadis Global SSL ICA G2, O=QuoVadis Limited, C=BM
Simple Name: QuoVadis Global SSL ICA G2
DNS Name: QuoVadis Global SSL ICA G2
[Serial Number]
0B19333C665EF2B82D72D7E12FD2D25A05312A34
[Not Before]
19-01-2023 14:46:22
[Not After]
19-01-2024 14:41:00
[Thumbprint]
F83071C72D994826072ABAA84AC1571979910B6E
[Signature Algorithm]
sha256RSA(1.2.840.113549.1.1.11)
[Public Key]
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0a 02 82 01 01 00 8d a8 dc 04 f6 d6 48 4c 7e 9c d6 54 9f ff 52 1a cc bb b3 74 52 42 c3 c5 a2 7f 91 27 55 9d 1b e7 c2 c2 70 8e b8 8f df 19 52 ea a5 84 d7 18 78 e6 40 92 df 74 4f 40 3d 32 b6 08 9d d6 41 d4 4f 8b 21 8a 8d 09 5b 6d 95 1a 41 c3 82 96 f2 7d fe 9a b5 83 19 6f 7e 24 34 46 d3 7c 1c fa 69 3b 0d 02 9a 76 a1 9a 8c b4 74 90 86 37 07 c5 59 7c 10 5b 70 bb 03 8d 5c 80 12 b4 dc 03 5a f3 db 08 20 a9 6e c2 56 d6 4b d1 bf 9c 3e 87 35 da d3 84 ec e1 97 a6 1b ed 46 c9 35 9a 25 30 28 39 84 ad 31 0c 82 8f 7a 9c 9a 24 27 9f 7f 6e 6b 28 f3 b8 b2 ce cc dd b8 2b 3c 22 c2 80 73 25 22 c1 d1 c7 31 ce e7 9b 96 99 db a4 66 34 91 dc 37 b0 6d cc d3 f2 e7 ab a8 3c 8b 0e c9 f4 75 1b 7d f8 d8 fe d0 bb 1d 37 5b 0f 4e fe 8d f2 03 a3 29 17 1d 11 a8 64 76 4e 2a 01 e3 6b 26 74 a7 af 33 f0 06 2f 60 3f 02 03 01 00 01
Parameters: 05 00
[Extensions]
* Essentiële beperkingen(2.5.29.19):
Subjecttype=Eindentiteit
Beperking voor padlengte=Geen
* Sleutel-id van CA(2.5.29.35):
Sleutel-id=911962ad5b17a730fbf0de3925b1bd8cb9b85127
* Toegang tot CA-gegevens(1.3.6.1.5.5.7.1.1):
[1]Informatietoegang voor instantie
Toegangsmethode=CA-verlener (1.3.6.1.5.5.7.48.2)
Alternatieve naam:
URL=http://trust.quovadisglobal.com/qvsslg2.crt
[2]Informatietoegang voor instantie
Toegangsmethode=Onlinestatus van het certificaat (1.3.6.1.5.5.7.48.1)
Alternatieve naam:
URL=http://ocsp.quovadisglobal.com
* Alternatieve naam voor onderwerp(2.5.29.17):
DNS-naam=*.pdok.nl
DNS-naam=pdok.nl
DNS-naam=s3.delivery.pdok.nl
* Certificaatbeleid(2.5.29.32):
[1]Certificaatbeleid:
Beleids-id=1.3.6.1.4.1.8024.0.2.100.1.1
[1,1]Beleidskwalificatiegegevens:
Beleidskwalificatie-id=CPS
Kwalificatie:
http://www.quovadisglobal.com/repository
[2]Certificaatbeleid:
Beleids-id=2.23.140.1.2.2
* Uitgebreid sleutelgebruik(2.5.29.37):
Clientauthenticatie (1.3.6.1.5.5.7.3.2)
Serverauthenticatie (1.3.6.1.5.5.7.3.1)
* CRL-distributiepunten(2.5.29.31):
[1]CRL-distributiepunt
Naam van distributiepunt:
Volledige naam:
URL=http://crl.quovadisglobal.com/qvsslg2.crl
* Identificatie van de onderwerpsleutel(2.5.29.14):
2e9b86fa830d091f68d65dc4d84291010d100752
* Sleutelgebruik(2.5.29.15):
Digitale handtekening, Sleutelcodering (a0)
* Lijst met SCT's(1.3.6.1.4.1.11129.2.4.2):
v1
dab6bf6b3fb5b6229f9bc2bb5c6be87091716cbb51848534bda43d3048d7fbab
donderdag 19 januari 2023 15:56:23
SHA256
ECDSA
30440220651ba18614d8731e89acf881cbb734b853d75b68520b81658f05eba10beb6c2602203cfe54e044c5cd55ba3854c894a59a9f46b0350cf40c58d9c47643850cd2132f
v1
76ff883f0ab6fb9551c261ccf587ba34b4a4cdbb29dc68420a9fe6674c5a3a74
donderdag 19 januari 2023 15:56:22
SHA256
ECDSA
3046022100e72d23788c0ebf5bc616ba74e21bda855bb32e4efd6691b8f4856203bf18ec28022100a169eaff1c8e3a558375b4a189ba416bef6e0c0197147867952b108802061064
v1
eecdd064d5db1acec55cb79db4cd13a23287467cbcecdec351485946711fb59b
donderdag 19 januari 2023 15:56:23
SHA256
ECDSA
30450221009390fd3752f5539373d9c439505d30fd054ab29e8f9e78510a6deeeb4a593eec0220420bf6ddfdc2e84f2fa4a9c840a818ee98baa7b97daea54f90a6fc2e6905621f
v1
5581d4c2169036014aea0b9b573c53f0c0e43878702508172fa3aa1d0713d30c
donderdag 19 januari 2023 15:56:23
SHA256
ECDSA
304502210085cf85a25186be333c14a2d442b9b72679f0ce574e8354542080484133be0cad02204682748df54699b9856f7c1a18e9db835a1cf4e456c14d25b91bd9debb9f2679
[SubjectAltNames]
DNS-naam=*.pdok.nl
DNS-naam=pdok.nl
DNS-naam=s3.delivery.pdok.nl
Hopelijk heb je hier wat aan?
Helemaal top! Ik heb voor de zekerheid nu een check op zowel 202 als 200, alleen nog even een paar duizend gebruikers informeren dat ze een nieuwe versie moeten installeren 
Ook bedankt voor de inspanning en het meedenken!
Dank, nee, dat is het connect request. Maar de inhoud zie je pas als je decypher https aanzet in de instellingen. (Er wordt dan een mitm proxy opgezet met self-signed certs.) Maar het is volgens mij niet meer nodig omdat @hulstg al iets heeft gevonden. Die reageert zo wel.
Krijg idd weer een 202, maar hierbij alsnog de request:
POST https://api.pdok.nl/lv/bgt/download/v1_0/full/custom HTTP/1.1
accept: application/json
User-Agent: Other
Content-Type: application/json; charset=utf-8
Host: api.pdok.nl
Content-Length: 591
{"featuretypes":["bak","begroeidterreindeel","bord","gebouwinstallatie","installatie","kast","kunstwerkdeel","mast","onbegroeidterreindeel","ondersteunendwaterdeel","ondersteunendwegdeel","openbareruimtelabel","overbruggingsdeel","overigbouwwerk","overigescheiding","paal","pand","put","scheiding","sensor","spoor","straatmeubilair","tunneldeel","vegetatieobject","waterdeel","waterinrichtingselement","wegdeel","weginrichtingselement"],"format":"citygml","geofilter":"POLYGON((182366.988 525283.260,176987.153 524700.599,178466.600 521025.920,181661.456 522779.242,182366.988 525283.260))"}
We zijn er inmiddels achter wat het issue is. We hebben het exacte request achterhaald. In de request staat de header Expect: 100-continue. Dit levert twee responses op, namelijk een 100 Continue en vervolgens een 202 Accepted. Dit is juist. Door de security wijziging was dit 100 Continue en vervolgens 200 OK geworden wat niet juist is. We gaan nadenken over een definitieve oplossing.
Maar jullie kregen zelf wel een 202 terug bij testen? Zijn er nog request parameters die van invloed kunnen zijn?
De Expect: 100-continue request header triggerd het probleem. Die zat bij onze testen niet in de request, maar die stopt InfraCAD wel in de request.
Ah, zal eens kijken of ik dat kan verhelpen.