我们使用了多个第三方,私人肥皂网络服务,它们在柏林都可以正常工作。 我们刚刚切换到rio,发现在触发ERemotable异常时,soap Web服务的行为现在有所不同。在柏林,即使http响应代码为500(内部服务器错误),我们也始终会收到ERemotable异常。出于某种原因(我不确定是有效的),当触发ERemotable异常时,我们消耗的Soap Web服务返回http 500错误。我们对此无能为力。但是,当我在RIO中运行相同的代码时,我们注意到我们不再获得任何ERemoteable异常,而是获得了HTTP状态代码为500的System.net异常,而像在柏林发生的可擦除异常也从未发生。
这是在未更改代码的情况下delphi berlin和rio之间的行为差异。
我发现在CheckResponseError
文件的Soap.SOAPHTTPTRans.pas
中触发了system.net异常,并且有一个事件FOnHttpError
,可以使用SetOnHttpError
过程来设置。使用该事件中的最后一个var action
参数,也可以将结果从heaError更改为heaSuccess。
如果我添加这样的事件使HTTP 500错误仍然被认为是成功的,我会再次获得ERemotable异常,而不是system.net异常,因为只有在结果为heaError时才会触发这些异常:>
procedure TBaseEnotWebserviceclient.HttpError(const HTTPReqResp: THTTPReqResp; const HTTPResponse: IHTTPResponse;
const Error: ESOAPHTTPException; var action: tsoAPHttpErroraction);
begin
if HTTPResponse.StatusCode = 500 then
action := heaSuccess;
end;
现在,尽管这行得通,但我想知道这是否会带来负面影响,并且我还想知道,柏林在处理soap时是否不会产生任何http错误,而只是在代码中走得更远,并在需要时触发了一个可渗透的异常。 >
可能的主要问题是,我如何使rio再次发挥作用,因为柏林提供的代码足以忽略http 500错误,还是我应该认为其他结果代码也能成功获得与我们相同的行为在柏林。在我看来,在ERemotable异常中可以被System.net异常吸收(来自CheckResponse函数),我真的不知道如何正确解决此问题,因为我们再次获得了所有ERemotable异常
编辑:刚在柏林Soap.SoapHttpTrans
的源代码中注意到了这一点。似乎在柏林,他们忽略了http 500状态代码,而在rio中不再这样做。
而rio他们现在只有这个: