Bug in TIdCustomHTTPServer.DoExecute (at least when used with TIdHTTPWebBrokerBridge)

[RenzoTel]

I found a bug in TIdCustomHTTPServer.DoExecute, which I believe is related to its use with TIdHTTPWebBrokerBridge: when the connection is closed by the remote client before the response has been written, the stream field of the TIdHTTPResponseInfo object can be assigned but is no longer valid (due to a mechanism I haven't explored that causes WebBroker to free the stream when the connection is closed). This causes an access violation in WriteContent and the system becomes very unstable.
I found that checking connected adding this line at current line 1500 of IdCustomHTTPServer.pas, (before the call to writeContent) solve the problem:

         if not LConn.Socket.Connected then
            break;

before of:

          // Write even though WriteContent will, may be a redirect or other
          if not LResponseInfo.HeaderHasBeenWritten then begin
            LResponseInfo.WriteHeader;
          end;

[rlebeau]

By default, WebBroker owns the TStream object that gets assigned to the TIdHTTPResponseInfo.ContentStream property. TIdHTTPWebBrokerBridge sets the TIdHTTPResponseInfo.FreeContentStream property to False so TIdHTTPResponseInfo won't try to free the TStream.

Even if the client did disconnect prematurely (which BTW, Connected would not detect if it were an abnormal disconnect, so your patch won't catch every scenario), the TStream object should remain alive while TIdHTTPServer is processing the request, as WebBroker's TWebResponse is not freed (thus freeing the TStream) until after the request handler is finished.

However, looking into TIdHTTPWebBrokerBridge's code, I see it does create and destroy WebBroker's TWebResponse from inside of the TIdHTTPServer.DoCommandGet() event handler, so what you describe might be possible if WebBroker assigns a ContentStream but does not send any response to the client (TWebResponse.Sent() returns False) and then TIdHTTPServer tries to send its own response after DoCommandGet() exits and the TWebResponse (and TStream) has already been destroyed.

So, a better fix might be to have TIdHTTPWebBrokerBridgeRequestHandler.DoCommandGet() reset the TIdHTTPResponseInfo.ContentStream property to nil after it has destroyed the TWebResponse. Or alternatively, if TWebResponse.FreeContentStream = True then have it set TWebResponse.FreeContentStream = False and TIdHTTPResponseInfo.FreeContentStream = True to take ownership of the TStream and free it after TIdHTTPServer is completely done using it.