TIdHTTP protocol transport safety

[Dmitriy M 10]

Using TIdHTTP is it possible to distinguish whether POST request has been received (processed) by the server and error occurred during transmission/read of response or whether request has not been received by the server at all? I feel like my planned solution has too many assumptions and is far from perfect.

begin
  // create and set up TIdHTTP instance
  IdHTTP.HTTPOptions := IdHTTP.HTTPOptions + [hoNoProtocolErrorException, hoWantProtocolErrorContent];
  try
    // prepare request
    IdHTTP.Post(API_END_POINT, RequestStream, ResponseStream);
    // check for response code and take actions
  except
    on E: EIdSocketError do
    begin
      // connection establishment error; the request was not processed
    end;
    on E: EIdConnectTimeout do
    begin
      // connection establishment error; the request was not processed
    end;

    on E: EIdReadTimeout do
    begin
      // response read error; the request was processed
    end;
    on E: EIdConnClosedGracefully do
    begin
      // response read error; the request was processed
    end;
  end;
end;

 

[aehimself 396]

Off: That is some nicely commented code!

[Remy Lebeau 1394]

8 hours ago, Dmitriy M said:

Using TIdHTTP is it possible to distinguish whether POST request has been received (processed) by the server and error occurred during transmission/read of response or whether request has not been received by the server at all?

In a word, no.  That is simply not how TCP works, let alone HTTP.  This is not limited to just TIdHTTP, but to any TCP/HTTP implementation.  Only the low-level TCP stack has access to the ACKs that indicate data packets have actually reached their destination.  Applications do not have access to that information.

 

[Fr0sT.Brutal 900]

10 hours ago, Dmitriy M said:

Using TIdHTTP is it possible to distinguish whether POST request has been received (processed) by the server and error occurred during transmission/read of response or whether request has not been received by the server at all?

Well you can't be sure client request has reached a server from client side until client starts receiving request.

Usually client doesn't need anything more than "connect failure" (means server is unreachable or the whole network is down), "request-response network failure" (any network issues during communication) and "request payload failure" (message is correct but issued error on server)