httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: svn commit: r442758 - in /httpd/httpd/trunk/modules/generators: mod_cgi.c mod_cgid.c
Date Thu, 14 Sep 2006 10:10:26 GMT
On 9/13/06, Nick Kew <nick@webthing.com> wrote:
> On Wednesday 13 September 2006 22:31, Jeff Trawick wrote:
> > On 9/13/06, Nick Kew <nick@webthing.com> 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.

%c already handles this.

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

Yes, I am supporting RĂ¼diger's proposition.  Don't make up some HTTP
status code for the aborted-connection condition.  We already have a
way to record this issue (%c).

Mime
View raw message