Wie oben beschrieben, habe ich nur die Tokyo-Sourcen vorliegen.
Ich nehme an, da hat sich zwei Versionen weiter schon was getan.
Ich vermute, dass du den Fehler in TWinHTTPClient.DoExecuteRequest bekommst.
Also beim Senden des Requests mit WinHttpSendRequest.
Das ist in Tokyo wie folgt gelöst (Zeile 855 ff. aus System.Net.HttpClient.Win):
Delphi-Quellcode:
// Send Request
LRes := WinHttpSendRequest(LRequest.FWRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, LDataLength, 0);
if not LRes then
begin
LastError := GetLastError;
case LastError of
ERROR_WINHTTP_SECURE_FAILURE:
Exit(TExecutionResult.ServerCertificateInvalid);
ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED:
Exit(TExecutionResult.ClientCertificateNeeded);
else
raise ENetHTTPClientException.CreateResFmt(@SNetHttpClientSendError, [GetLastError, SysErrorMessage(GetLastError, GLib.Handle)]);
end;
end;
Vom Fehlertext her, bekommst du ja einen ERROR_WINHTTP_SECURE_FAILURE ("Es ist ein Sicherheitsfehler aufgetreten").
Das wurde hier in 10.2 Tokyo noch mit einem einfachen Enum-Wert als Rückgabe gelöst.
Ich könnte mir vorstellen, dass dies in 10.4 Sydney auf den ENetHTTPClientException.CreateResFmt geht.
Denn
SNetHttpClientSendError = 'Fehler beim Senden der Daten: (%d) %s';
ist der mittlere Teil deiner Fehlermeldung.
Der vordere Teil (sRESTRequestFailed) kommt aus dem except-Block von TCustomRESTRequest.Execute (Rest.Client),
Delphi-Quellcode:
// Unknown error, might even be on the client side. raise it!
on E:
Exception do
begin
// If Execute raises an Exception, then the developer should have look into the actual BaseException
raise ERESTException.CreateFmt(sRESTRequestFailed, [E.
Message]);
end;
Wie dem auch sein, für ERROR_WINHTTP_SECURE_FAILURE sagt die
MSDN (
https://docs.microsoft.com/en-us/win...psendrequest):
Zitat:
One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server.
To determine what type of error was encountered, verify through a WINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification in a status callback function.
For more information, see WINHTTP_STATUS_CALLBACK.
Was uns hierzu führt:
https://docs.microsoft.com/en-us/win...tatus_callback
Du könntest also durch das setzen einer Callback mehr Information erhalten, warum es bei dir scheitert (via WinHttpSetStatusCallback ->
https://docs.microsoft.com/en-us/win...statuscallback).
In Tokyo ist dafür nichts vorgesehen bzw. ist das in TWinHTTPClient.Create auskommentiert.
Entweder gibt es in Sydney dann Möglichkeiten dafür ODER du kopierst dir die System.Net.HttpClient.Win in dein Projekt und veränderst sie entsprechend, um mehr Informationen loggen zu können.