Mijn vraag
Wij hebben op mijn werk de situatie dat we XML web services aanroepen van leveranciers via HTTPS. Uiteraard gebruiken we hier (op WSDL gebaseerde) automatisch gegenereerde proxy classes voor en is het vaak lastig om te zien met welke XML we deze aanvragen doen.
Vroeger gebruikte ik WireShark om dit af te vangen, maar met HTTPS wordt dat hem niet meer
Nu hadden we vandaag weer een situatie waarbij een aanvraag van ons niet werd goedgekeurd door de leverancier, en wij de request XML wilden inspecteren... uiteindelijk heb ik een simpele HTTP handler gemaakt die de input helemaal leest en heb ik onze client met debugger eraan naar de URL van mijn HTTP handler gewezen, zodat ik alsnog de XML kon inspecteren (en vervolgens kon copy-pasten naar Postman om hem los te testen / tweaken).
Anyways, dit is allemaal erg omslachtig en het voelt een beetje nutteloos om die HTTP handler te gaan uitbreiden etc.
Er is vast een handig trucje / tooltje dat ik kan gebruiken hiervoor
Relevante software en hardware die ik gebruik
.NET framework 4.5.2 en ouderwetse Web Service references (geen WCF). Gezien de grote hoeveelheden web services is het ook niet aan te raden de implementatie te wijzigen.
Wat ik al gevonden of geprobeerd heb
Zelf HTTP handler gemaakt en request afgevangen door de client naar mijn handler URL te wijzen, maar dit kan vast handiger.
We erven ook al over van Microsoft.Web.Services3.WebServicesClientProtocol, waardoor we beschikken over een RequestSoapContext en ResponseSoapContext. Helaas is de RequestSoapContext vaak niet gevuld in foutsituaties, waardoor we geen Envelope.InnerXml kunnen opvragen en er dus alsnog niks aan hebben.
Dit is typisch zo'n dingetje dat eens in de 3 maanden terugkomt ofzo, waardoor het elke keer prutsen is, omdat niemand het een keer goed uitzoekt
Of documenteert
Alvast bedankt
Wij hebben op mijn werk de situatie dat we XML web services aanroepen van leveranciers via HTTPS. Uiteraard gebruiken we hier (op WSDL gebaseerde) automatisch gegenereerde proxy classes voor en is het vaak lastig om te zien met welke XML we deze aanvragen doen.
Vroeger gebruikte ik WireShark om dit af te vangen, maar met HTTPS wordt dat hem niet meer
Nu hadden we vandaag weer een situatie waarbij een aanvraag van ons niet werd goedgekeurd door de leverancier, en wij de request XML wilden inspecteren... uiteindelijk heb ik een simpele HTTP handler gemaakt die de input helemaal leest en heb ik onze client met debugger eraan naar de URL van mijn HTTP handler gewezen, zodat ik alsnog de XML kon inspecteren (en vervolgens kon copy-pasten naar Postman om hem los te testen / tweaken).
Anyways, dit is allemaal erg omslachtig en het voelt een beetje nutteloos om die HTTP handler te gaan uitbreiden etc.
Er is vast een handig trucje / tooltje dat ik kan gebruiken hiervoor
Relevante software en hardware die ik gebruik
.NET framework 4.5.2 en ouderwetse Web Service references (geen WCF). Gezien de grote hoeveelheden web services is het ook niet aan te raden de implementatie te wijzigen.
Wat ik al gevonden of geprobeerd heb
Zelf HTTP handler gemaakt en request afgevangen door de client naar mijn handler URL te wijzen, maar dit kan vast handiger.
We erven ook al over van Microsoft.Web.Services3.WebServicesClientProtocol, waardoor we beschikken over een RequestSoapContext en ResponseSoapContext. Helaas is de RequestSoapContext vaak niet gevuld in foutsituaties, waardoor we geen Envelope.InnerXml kunnen opvragen en er dus alsnog niks aan hebben.
Dit is typisch zo'n dingetje dat eens in de 3 maanden terugkomt ofzo, waardoor het elke keer prutsen is, omdat niemand het een keer goed uitzoekt

Alvast bedankt
Ask yourself if you are happy and then you cease to be.