From: Frank.Swarbrick@efirstbank.com   
      
   Is there a guideline on how to handle errors on the server when the   
   application generating the response fails for some reason?  Is closing the   
   connection the only option to signify to the client that the server process   
   has failed?  If the server process fails prior to sending any part of the   
   response it can, of course, use an HTTP status code specifying an error.   
   But once the server has started sending the response, if the server process   
   fails there appears to be no alternative other than just closing the socket.   
    Seems to me it would be useful to send the final (0) chunk and then some   
   sort of trailing header telling the client not to use the response, but   
   keeping the socket open.  But it appears that trailing headers should not be   
   depended on, so perhaps this is not a good idea.   
      
   In this case the HTTP user-agent is not a browser, but is rather a custom   
   application using HTTP/1.1 persistent connections to communicate with a   
   server.  So maybe I could use trailing headers after all, but I've seen no   
   indication that this is a good idea.   
      
   Is there a third alternative I've not thought of?   
      
   My apologies if I've used some terms incorrectly...   
      
   Thanks!   
      
   Frank   
      
      
   --   
      
   Frank Swarbrick   
   Applications Architect - Mainframe Applications Development   
   FirstBank Data Corporation - Lakewood, CO  USA   
   P: 303-235-1403   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)