DHL API über winhttp

[Signum]

Hallo,

ich versuche die DHL Soap API für den Paketversand über die winhttp.dll anzusprechen.

Bei Requests, die mit SoapUI einen Response erhalten, erhalte ich bei einem Aufruf über WinHttpSendRequest keine Antwort. WinHttpReceiveResponse und WinHttpReadData liefern nur 0 Bytes.

Wenn ich den Status nach WinHttpReceiveResponse abfrage, erhalte ich eine 401, obwohl ich https verwende.

Es erfolgen auch keinerlei Fehlermeldungen, die CIG-Authentifizierung ist scheinbar auch erfolgreich, denn sonst erhalte ich eine signifikante Fehlermeldung.

Ich habe schon mit versucht mit WinHttpSetOption und WINHTTP_OPTION_SECURE_PROTOCOLS auf TLS 1 umzustellen, das hat aber auch nichts gebracht. Der

DHL Support verwies auf die neuen Verschlüsselungsverfahren und gibt eine Reihe von Cipher Suites vor, nur wie kann man die bei WinHTTP vorgeben?

Hat jemand hier eine aktuelle funktionierende Anbindung zu DHL und kann mir da einige Tipps geben. Älter Lösungen habe ich hier schon gesehen, aber die funktionieren leider nicht mehr.

[mjustin]

Zitat von Signum:

Bei Requests, die mit SoapUI einen Response erhalten, erhalte ich bei einem Aufruf über WinHttpSendRequest keine Antwort. WinHttpReceiveResponse und WinHttpReadData liefern nur 0 Bytes.

Sieht aus als ob es ein spezielles Problem von WinHTTP ist. Aus dem normalen Webbrowser kann die SOAP Endpunkt Adresse vermutlich problemlos erreicht werden?

Die Cipher Suites des HTTPS Servers von DHL kann man z.B. unter https://www.ssllabs.com/ssltest/ abfragen, die Diagnose liefert auch Hinweise zu speziellen Inkompatibilitäten.

Wir greifen auch auf DHL zu, allerdings gibt es verschiedene Web Services. Welche Endpunkt Adresse ist es konkret?

[Signum]

Hallo,

zur Zeit gehe ich über https://cig.dhl.de/services/sandbox/soap und teste das ganze mit einem CreateShipmentDDRequest

Ich hab mir auch die Komponente über WSDL erzeugt, aber noch nicht weiter getestet.

Da ich das ganze später auch in eine externen Prozess in C++ auslagern will, wäre mir winhttp lieber.

Wie sprecht Ihr den den Web-Service an?

[mquadrat]

Wie ist die API denn abgesichert? 401 könnte auch der Start einer Digest-Authentication sein. Dort wird die Challenge mit einem 401 geschickt und der Server wartet anschließend auf die Response.

[mjustin]

Zitat von Signum:

Wie sprecht Ihr den den Web-Service an?

Der Endpunkt https://nolb.dhl.de/nextt-online-bus...bpublicservlet wird über Indy's HTTP Komponente abgefragt.

Der Hinweis auf den 401 Status Code sehe ich als "besten Kandidaten" für die Fehlersuche. 401 ist allerdings nicht Digest-spezfisch. Es kan auch eine einfache Basic-Uathentication sein. Bei Aufruf des Endpunkts in meinem Browser erscheint ein Basic Auth Logindialog und im HTTP Antwortheader steht

WWW-Authenticate:"Basic realm="CIG Sandbox Services""

[mjustin]

Zitat von Signum:

zur Zeit gehe ich über https://cig.dhl.de/services/sandbox/soap und teste das ganze mit einem CreateShipmentDDRequest

Versuche einfach mal die Credentials direkt in der URL anzugeben

https://username:[e-mail]...s/sandbox/soap

(Siehe http://stackoverflow.com/questions/2...and-encryption)

[Signum]

Die Zugangsdaten setze ich ja schon mit

WinHttpSetCredentials (hRequest, WINHTTP_AUTH_TARGET_SERVER, WINHTTP_AUTH_SCHEME_BASIC, UserName, Password, nil);

Wenn ich da falsche Daten angebe erfolgt auch eine klare Fehlermeldung im Response.

[mjustin]

Zitat von Signum:

Die Zugangsdaten setze ich ja schon mit

WinHttpSetCredentials (hRequest, WINHTTP_AUTH_TARGET_SERVER, WINHTTP_AUTH_SCHEME_BASIC, UserName, Password, nil);

Wenn ich da falsche Daten angebe erfolgt auch eine klare Fehlermeldung im Response.

Ok, als nächstes würde ich dann Fiddler2 als Proxy in die Verbindung einfügen und sehen, was sich bei WinHTTP anders verhält als bei SoapUI. Also beide Request / Responseprotokolle vergleichen.

[mquadrat]

mhh bei Basic müsste Pre-Authentication eigentlich funktionieren. Fiddler ist auf jeden Fall das Mittel der Wahl.

Wenn man nicht mit Pre-Authentication arbeitet, dann sieht der Workflow für die Anmeldung laut MSDN übrigens so aus:

Zitat:

A typical WinHTTP application completes the following steps in order to handle authentication.
Request a resource with WinHttpOpenRequest and WinHttpSendRequest.
Check the response headers with WinHttpQueryHeaders.
If a 401 or 407 status code is returned indicating that authentication is required, call WinHttpQueryAuthSchemes to find an acceptable scheme.
Set the authentication scheme, username, and password with WinHttpSetCredentials.
Resend the request with the same request handle by calling WinHttpSendRequest.

[mquadrat]

Aus purer Neugier: Warum eigentlich über WinHTTP?