From: Frank.Swarbrick@efirstbank.com   
      
   Ugh is right!   
      
   I assume this is a fairly uncommon occurance?  Seems to me that it would   
   have been something that could have been handled in HTTP/1.1 had someone   
   thought to do it.  Ah well, water and bridges and spilled milk and all...   
      
   By the way, is there a more appropriate newsgroup for HTTP discussions?   
      
   Thanks!   
      
   Frank   
   --   
      
   Frank Swarbrick   
   Applications Architect - Mainframe Applications Development   
   FirstBank Data Corporation - Lakewood, CO  USA   
   P: 303-235-1403   
      
      
   n 10/10/2010 at 6:53 AM, in message   
   , Rob   
   Warnock wrote:   
   > Barry Margolin   wrote:   
   > +---------------   
   > |  rpw3@rpw3.org (Rob Warnock) wrote:   
   > | > Frank Swarbrick  wrote:   
   > | > +---------------   
   > | > | 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?  ...   
   > | > +---------------   
   > | >   
   > | > RFC 2616 "HTTP/1.1" specifically addresses this:   
   > ...   
   > | >     8.2.2 Monitoring Connections for Error Status Messages   
   > | >        An HTTP/1.1 (or later) client sending a message-body SHOULD   
   > monitor   
   > | >        the network connection for an error status ...   
   > ...   
   > | Isn't the OP asking about the server, not the client?  And the error   
   > | he's asking about is from the application generating the data being   
   > | transmitted, not the network.   
   > +---------------   
   >   
   > Oops! Yes, you're right. I misread his question. In that case, if   
   > the server is using chunked transfer-coding it could use trailers   
   > to indicate the error to the client. [How the server determines that   
   > the application has errored is an internal design decision that doesn't   
   > need to be exposed to the 'Net.]   
   >   
   > Hmmm... The set of headers permitted in trailers is somewhat limited,   
   > the "entity-header" set defined in Section 7.1. The Status-Code element   
   > is *not* one of those, and a "200" will probably have already been sent,   
   > so it's not clear to me how to unambiguously signal an error.   
   >   
   > A mismatching Content-Length header won't work, since Section 4.4   
   > *requires* that such be ignored:   
   >   
   >     If a message is received with both a Transfer-Encoding header   
   > field...   
   >   
   > [e.g., "chunked"]   
   >   
   >     ...and a Content-Length header field, the latter MUST be ignored.   
   >   
   > The only thing I can think of is for the server to unexpectedly close   
   > the connection in the middle of a chunk. Ugh.   
   >   
   >   
   > -Rob   
   >   
   > -----   
   > Rob Warnock			   
   > 627 26th Avenue			   
   > San Mateo, CA 94403		(650)572-2607   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)