W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: mid-course errors

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
Message-Id: <9704211551.aa24045@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3113
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.

Received on Monday, 21 April 1997 16:03:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC