httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: filter return values
Date Sun, 31 Dec 2000 23:10:55 GMT
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/

Mime
View raw message