- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Mon, 21 Apr 1997 15:51:26 -0700
- To: Dave Kristol <dmk@research.bell-labs.com>
- Cc: http-wg@cuckoo.hpl.hp.com
In message <9704141331.AA04939@zp>, Dave Kristol writes: >Here's something that has puzzled me about HTTP server >implementations. What happens if the server encounters an error after >it sends, say, a "200 OK" response and part of the entity body? >Example cases include an origin server that gets a timeout from a CGI >part way through relaying the CGI's output, or when a proxy acts as a >pure relay and, for example, its connection to the next hop server (is >that upstream or downstream? :-) breaks. The server has no way to >signal to its client that the previously claimed success has now turned >into an error. The only useful thing a server could say at that point is the equivalent of 500 Internal Server Error, which is no better than just cutting-off transmission of the message and closing the connection. If the message is properly delimited, the client should be capable of seeing that something is missing and act appropriately. A multiplexing HTTP should be capable of terminating a "thread" early without harming the rest of the connection, so I think trying to get HTTP/1.x to handle it would be a mistake. ....Roy
Received on Monday, 21 April 1997 16:03:41 UTC