Reporting errors from filters

[rb...@covalent.net]

This issue has come up before, but we never dealt with it.  We need to
deal with it now though.  Filters must have a way to actually report a
specific error to a handler, so that the server can report
errors.  Currently, the filters are supposed to return an HTTP error value
(at least that is the current design, but not implementation), but we
don't implement that well.

One of the problems, is that ap_r* returns an int, but those functions are
setup to return either -1 or the number of bytes written.  But, that
doesn't work for filters.

I propose that we have ap_r* return an HTTP status code, so that filters
can return an HTTP status code, and we can get good errors from the
filter.

Thoughts?

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Reporting errors from filters

[rb...@covalent.net]

> > > Do you mean report errors for the error_log or for an HTTP error response?
> > > I think the former, since we are already in mid-stream of the response
> > > at that stage.
> > 
> > Actually, I meant the latter.
> 
> Oh, in that case, what I would do is define an error bucket (just a
> specific case of response metadata) and send that downstream to
> be handled directly by the http filter.  That bucket could contain
> the errno (if any) and a meaningful string.

Oooooooo........  Very nice and clean.  I like it a lot!!!!  Expect that
patch to go in tonight.  Thanks a lot Roy.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Reporting errors from filters

["Roy T. Fielding" <fi...@ebuilt.com>]

> > Do you mean report errors for the error_log or for an HTTP error response?
> > I think the former, since we are already in mid-stream of the response
> > at that stage.
> 
> Actually, I meant the latter.

Oh, in that case, what I would do is define an error bucket (just a
specific case of response metadata) and send that downstream to
be handled directly by the http filter.  That bucket could contain
the errno (if any) and a meaningful string.

....Roy

Re: Reporting errors from filters

[rb...@covalent.net]

> > This issue has come up before, but we never dealt with it.  We need to
> > deal with it now though.  Filters must have a way to actually report a
> > specific error to a handler, so that the server can report
> > errors.  Currently, the filters are supposed to return an HTTP error value
> > (at least that is the current design, but not implementation), but we
> > don't implement that well.
> 
> Do you mean report errors for the error_log or for an HTTP error response?
> I think the former, since we are already in mid-stream of the response
> at that stage.

Actually, I meant the latter.  Reporting errors for the error_log can be
done by the filter itself.  We may not actually be in the middle of a
response at this stage.  Picture this scenario:

I have a filter that scans the data, comparing values in the response with
data I stored in a database.  I don't want to serve the file unless
everything matches.  I am willing to buffer all the data, and save it to
disk for this protection, but I require this protection.  I desperately
want to do this in a filter, but I can't return a valid HTTP error code to
the server.

Even more likely however, is a filter that checks something on the very
first call, and returns an error if something is wrong, or continues if
everything is good.  Right now, we can't do that.

> > I propose that we have ap_r* return an HTTP status code, so that filters
> > can return an HTTP status code, and we can get good errors from the
> > filter.
> 
> The problem is that filter errors are not going to be HTTP errors,
> unless we are talking about the input filters.  Wouldn't it be easier
> to register a function pointer within the filter object that can
> be called when an error occurs?

I do need a way to create an HTTP error from within a filter.  I believe
others will need this as well.  Filter writers will need to understand
that they can't return an error code after they call ap_pass_brigade, but
that is the same rule we have for headers, so I don't believe that is a
big deal.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Reporting errors from filters

["Roy T. Fielding" <fi...@ebuilt.com>]

> This issue has come up before, but we never dealt with it.  We need to
> deal with it now though.  Filters must have a way to actually report a
> specific error to a handler, so that the server can report
> errors.  Currently, the filters are supposed to return an HTTP error value
> (at least that is the current design, but not implementation), but we
> don't implement that well.

Do you mean report errors for the error_log or for an HTTP error response?
I think the former, since we are already in mid-stream of the response
at that stage.

> One of the problems, is that ap_r* returns an int, but those functions are
> setup to return either -1 or the number of bytes written.  But, that
> doesn't work for filters.

Why not record the error in the ap_r* functions?

> I propose that we have ap_r* return an HTTP status code, so that filters
> can return an HTTP status code, and we can get good errors from the
> filter.

The problem is that filter errors are not going to be HTTP errors,
unless we are talking about the input filters.  Wouldn't it be easier
to register a function pointer within the filter object that can
be called when an error occurs?

....Roy