httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <>
Subject Re: svn commit: r442758 - in /httpd/httpd/trunk/modules/generators: mod_cgi.c mod_cgid.c
Date Wed, 13 Sep 2006 21:31:58 GMT
On 9/13/06, Nick Kew <> wrote:
> On Wednesday 13 September 2006 20:33, Ruediger Pluem wrote:
> > Wouldn't it make sense to return OK even if rv != APR_SUCCESS in the case
> > that c->aborted is set, just like in the default handler?
> I'm not sure.  Presumably if c->aborted is set, then we have no client
> to respond to, so this is just about housekeeping and what ends up
> in the logs.  Do we want to log a successful POST or PUT when it wasn't?

Here is my understanding:

The connection status (%c) is what the admin should check to confirm
that there were no network I/O issues (at least none that caused TCP
to give us an error up through the point when the request was

In many cases, an HTTP status code has already been written to the
client before the I/O problem occurs anyway so changing the status
code doesn't make sense.  A failure to read a request body would be
prior to the point where we could write a status code, but I don't see
why the log analysis heuristic should be different.

500 implies that there could be an action to take to resolve a problem
(e.g., screwy filters bungled the return codes; screwy configuration;
out of memory; ???).  It doesn't apply when somebody bored with an
upload hit the Stop button.

View raw message