You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2000/12/31 21:09:50 UTC
filter return values
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?
Re: filter return values
Posted by rb...@covalent.net.
> 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.
I don't believe this matters. It is all about context. In this case, we
should never see an APR error code, so a conflict won't bite us. I agree
this is a bit hoaky, but it is the better solution for reasons I mention
below.
> 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.
I have multiple problems with this. First of all, you are asking all
handlers to have logic to convert an APR error code into an HTTP error
code. Duplicating logic like this is asking for trouble.
Even more troubling IMHO, is that you are asking handlers to just figure
out what happened and what the error code should be. That is a really bad
idea. Take for example, and antivirus filter. If I find a virus, I don't
want the client to see HTTP_INTERNAL_SERVER_ERROR. I want them to get a
503, SERVICE UNAVAILABLE, or something like that. This wasn't a server
error, it was a condition that I decided I didn't want to serve pages
for. Now, if we return APR error codes from filters, then EVERY handler
has to have logic to figure out which error code I meant. What happens
when I plug my antivirus module into a server with a handler that doesn't
have this logic? I get INTERNAL SERVER ERROR, and my users get
annoyed. IMO, this is a VERY bad idea.
> 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.
There is no reason the save that information in this case. We don't
really care about it. The filter should be logging the failure condition,
because we don't want to ask the handler to do that. The handler can't
really do anything with that information, because it doesn't really know
what the filter was trying to do, or even which filter failed. In this
case, the information we want to preserve, is what error code should be
returned to the browser, not what went wrong internally. That information
is preserved in the error log.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: filter return values
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: filter return values
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: filter return values
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: filter return values
Posted by rb...@covalent.net.
> > 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.
>
> if i return the error code from the filter callback i still get 'document
> contains no data'. however, deeper down i can check if the return value
> from ap_pass_brigade() ap_is_HTTP_SERVER_ERROR(), which i guess will have
> to do. would be nice if filter callbacks could return a server error to
> apache though. esp. since not all handlers will use ap_pass_brigade(),
> e.g. those that use ap_rwrite(), which doesn't even check the return value
> of ap_pass_brigade().
This is a bug that we will need to fix. Greg and I are currently
discussing this.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: filter return values
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 31 Dec 2000 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.
if i return the error code from the filter callback i still get 'document
contains no data'. however, deeper down i can check if the return value
from ap_pass_brigade() ap_is_HTTP_SERVER_ERROR(), which i guess will have
to do. would be nice if filter callbacks could return a server error to
apache though. esp. since not all handlers will use ap_pass_brigade(),
e.g. those that use ap_rwrite(), which doesn't even check the return value
of ap_pass_brigade().
Re: filter return values
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------