Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 98803 invoked by uid 500); 22 Mar 2002 23:15:48 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 98790 invoked from network); 22 Mar 2002 23:15:48 -0000 Errors-To: Message-Id: <5.1.0.14.2.20020322171234.022f3b40@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Mar 2002 17:15:27 -0600 To: dev@httpd.apache.org From: "William A. Rowe, Jr." Subject: RE: [PATCH] invalid HTTP status codes in access log In-Reply-To: <002d01c1d1f5$7637b6c0$5200000a@KOJ> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 05:01 PM 3/22/2002, you wrote: > > > Filters shouldn't return apr_status_t's, because there is nothing > > > that the core can do with a status code. True, they can do nothing with the apr_status_t code, any more than they can do anything with the HTTP_SOME_CODE or any other magic number. But an apr_status_t is far more descriptive of what went wrong in the filter stack, and it doesn't bind filters as tightly to HTTP server applications. I know there was a great deal of interest in using them in a client, and there will certainly be other network applications over time. Binding the result to HTTP code seems silly, Cliff is right --- if there is any non-APR_SUCCESS result, the core should 500, something really broke. Bill