httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: [PATCH] filtering and canned error responses
Date Tue, 05 Sep 2000 14:08:03 GMT

In a message dated 00-09-05 12:52:14 EDT, Ryan writes...

> If we have a filter that converts from HTML to WML, then
> we want the error page to go through that filter.

Exactly.

The ONLY issue with this current message thread 
( using the HTML to WML example ) is what if the 
HTML to WML filter itself has generated the ERROR and
that error page is the one that needs to be 'sent back'?

Now what? Since the very thing that was supposed to be
doing the right client formatting and sending it the response in the only
format it will understand ( because a WML browser was detected
in the inbound User-Agent field ) is the very thing causing
the problem then what is the correct 'punt'?

text/plain is actually OK for most WML browsers so perhaps this
isn't the best example but the concern is still valid. What if the
filter that is supposed to send the right formatted response is the
one that can't even send an error page because it's broken?

I guess at some point it's the old joke about 'If the I/O sub-system
is hosed just bypass it'  or 'Keyboard failure, press F1 to continue'.

Some things are just going to HAVE to work 100% or they are just
plain broken and must be fixed ASAP.

Truth is this...

Some filters that are installed which generate ERRORS and
need to send back error pages can/should be bypassed 
as the actual error page is heading out the door... IF they are
the actual offending filter... but other filters that are not involved
and working fine should still process the page for the User-Agent
( E.g. HTML to WML ).

If some ESSENTIAL filter involved in the correct delivery of
content ( including error pages ) to a client is the one that
has coughed up... well... then what can you do? Assume
text/plain? text/html? Maybe, maybe not.

If some essential filter is that broken then all you can really
do is just close the connection and report the problem in a log
and hope it gets fixed ASAP.

...or just send an ISO/9000 plain text message saying...
"Keyboard error... press F1 to continue"?

None of this should slow the train down. It's all 'what if' scenarios
anyway and can be dealt with as they happen with simple patches.

Yours...
Kevin Kiley
http://www.RemoteCommunications.com
http://www.rctp.com - Online Internet Content Compression Server.




Mime
View raw message