> Date: Mon, 13 Jun 1994 14:29:02 +0200
> From: John C. Mallery <JCMa@reagan.ai.mit.edu>
>
> We need a status code for internal use in clients and servers when a
> connection times out before the transaction is complete.
We should distinguish betweeninternal client codes and codes sent
across the net.
Clearly. I'm not dealing with clients at the moment.
The HTTP status codes are sent over the net and
have a significance only in the context of the HTTP transaction.
So for example, if a client requests from a proxy which goes
out to a server, and the connection between the proxy and the
server times out, then from the point of view of the primary
connection between the client and the proxy, the return code
should be something like
500 Something went wrong: underlying service timed out
A little too general to be useful for much of anything.
with an explanatory message including ifnromation about the
actual error, for diagnostic purposes. If the proxy has a code
for "timeout", then it would need codes for all the N things
which can happen to underlying services, from core dumps to
ball lightning.
My immediate problem was the status code to record in the common logfile
format for my server. 500 is overly general.
A bug with numeric codes is that they do not directly encode the error
taxonomy. For examples, see the
http://clinton.ai.mit.edu/code/server/http-conditions.lisp
Are you suggesting two different timeout codes? One for proxy servers and
another for clients (which we don't advertise)?
In any event, what does the server stuff in the log file when the client times
out?