httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: svn commit: r442758 - in /httpd/httpd/trunk/modules/generators: mod_cgi.c mod_cgid.c
Date Wed, 13 Sep 2006 22:25:07 GMT
On Wednesday 13 September 2006 22:31, Jeff Trawick wrote:
> 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
> complete).
> 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.

So we should log an error, not a success.  500 won't always be the ideal
error, but I don't really see how we can do better within the current API.

> 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.

So are you supporting RĂ¼diger's proposition?  I can accept that if it's
the popular view.

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message