Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sun, 31 Dec 2000 15:28:20 -0800
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: filter return values
Message-ID: <20001231152820.H9752@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <20001231151055.C9752@lyra.org>
 <Pine.LNX.4.21.0012311511450.5650-100000@koj>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0012311511450.5650-100000@koj>;
 from rbb@covalent.net on Sun, Dec 31, 2000 at 03:14:14PM -0800

I think that it *is* something that we're going to say. Putting an HTTP
status code (e.g. OK, DONE, or HTTP_CONFLICT) into an apr_status_t could
conflict with an errno value. Or a Windows or OS/2 error. Or whatever.

Filters should return an APR status code. I don't believe they have any
business returning HTTP codes (consider that filters "know nothing" about
HTTP). The content generator would get an APR status from its
ap_pass_brigade call and will typically map that into
HTTP_INTERNAL_SERVER_ERROR. Cover functions such as ap_rwrite() which *do*
return HTTP status codes would do that mapping.

The other reason for returning an apr_status_t from the filter is to prevent
loss of information for as long as possible. If we mapped directly to
HTTP_INTERNAL_SERVER_ERROR, then it will be much harder to realize that the
error was caused by (e.g.) a pipe that shut down unexpectedly.

Cheers,
-g

On Sun, Dec 31, 2000 at 03:14:14PM -0800, rbb@covalent.net wrote:
> 
> This is untrue.  We are using apr_status_t's throughout the code the
> return non-APR error values.  This is a fact of life.  There is nothing
> about the apr_status_t that says it *must* be an APR error value.  It is a
> convenient type to use for general status values, whether those are APR
> status values, or not.
> 
> If this is something we are going to say, then we need to make the filters
> return simple integers, and we need to scour the code and convert a bunch
> of other apr_status_t's to int as well.
> 
> Ryan
> 
> On Sun, 31 Dec 2000, Greg Stein wrote:
> 
> > The HTTP status codes are not "in" the apr_status_t number space. They
> > *cannot* be returned within an apr_status_t.
> > 
> > Filters should return APR status values. Not HTTP status codes.
> > 
> > It would be possible to create "user" APR status codes (defined in an Apache
> > header) that match the HTTP status codes.
> > 
> > Cheers,
> > -g
> > 
> > On Sun, Dec 31, 2000 at 02:58:07PM -0800, rbb@covalent.net wrote:
> > > 
> > > What happens when you return the actual HTTP error code.  The way this is
> > > supposed to work, is that a filter returns an HTTP error code, and the
> > > handler should detect that, and return the same code.  From there, it
> > > should work the same way returning an HTTP error from a handler worked in
> > > 1.3.
> > > 
> > > Ryan
> > > 
> > > On Sun, 31 Dec 2000, Doug MacEachern wrote:
> > > 
> > > > filters return an apr_status_t, is there a status to trigger
> > > > HTTP_INTERNAL_SERVER_ERROR?  for example, the filter callback calls a
> > > > Perl routine that throws a Perl runtime error (e.g. Perl method not found,
> > > > syntax error, etc.)  if i return something like APR_EINVAL i get 'document
> > > > contains no data'.  i can pass the brigade untouched, but that doesn't
> > > > seem right to ignore the error.  do i need to generate my own server error
> > > > brigade?  that doesn't seem right either, how would ErrorDocument's catch
> > > > that?
> > > > 
> > > > 
> > > 
> > > 
> > > _______________________________________________________________________________
> > > Ryan Bloom                        	rbb@apache.org
> > > 406 29th St.
> > > San Francisco, CA 94131
> > > -------------------------------------------------------------------------------
> > 
> > -- 
> > Greg Stein, http://www.lyra.org/
> > 
> > 
> 
> 
> _______________________________________________________________________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------

-- 
Greg Stein, http://www.lyra.org/