httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] filtering and canned error responses
Date Sat, 02 Sep 2000 15:35:20 GMT

> I disagree completely with the premise that all filters act on tags in
> a fashion similar to mod_include.  That is a debilitating requirement.
> Certain filters can work that way and certain ones can't.  It is
> better to disallow filtering on the error strings than to require that
> filters sanity-check their input data (not all filters can even do
> that).  (Besides, the less code between an error message and the
> network the better...  Sending an error message should be a relatively
> simple.)

But who's to say that we don't want all filters acting on those errors.  I
see a few cases, filters that add data to all output, filters that add
data on tags, and filters that modify some characteristic of the
data.  

Tags are not an issue in this case, because we all agree that any
errors Apache generates won't have tags.

Adding data to all output (I'm thinking header and trailer documents that
identify the site, or add a logo, or something like that) may want to be
used on error documents.

Filters that modify the data (I'm thinking charset or automatic langauge
translation) are very useful, especially on error pages.  These aren't
connection filters, they are content filters.

Of the three types I can see for filters, one isn't an issue, and the
other two are may want to filter the error doc.

> If the administrator wants filter processing on an error document she
> can use a redirect, so there is no big loss here.

But why bother with this.  What is the problem we are trying to solve with
this?  To me, it seems very straightforward that the error docs are put
into a bucket brigade with an EOS, because know that the doc is done, and
we send it down the filter stack.  This doesn't try to avoid the filter
logic we already have and it should work.  Where is the issue?

> I'm not sure I understand "canned errors generated by mistakes in
> SSIs."  Are you talking about a failed subrequest?

Take a look at mod_include.  We return the string "[an error occurred
while processing this directive]" whenever we encounter an error in
processing an SSI tag.  We don't want to send those out without filtering
them.  Also, how does this affect sub-requests?  If I have data that is
being buffered by some filter, and a filter higher-up sends a canned-error
response, won't the output be all messed up, because it won't wait for the
data sitting in the lower filter?

Ryan

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


Mime
View raw message