httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] filtering and canned error responses
Date Tue, 05 Sep 2000 15:26:37 GMT

In a message dated 00-09-05 14:16:51 EDT, Ryan writes...

> > 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'?
>  Quick question.  Is this an issue?  

For HTTP requests, not really. 

Consider this. When it comes to legitimate HTTP
errors there is NOTHING that says you ever have to return 
any body data at all. Period. If anything that happens qualifies
as a legit HTTP error ( If all else fails, 500 Internal Server ) then
all you have to send is 'HTTP 1/1 500'. That's it. Responsibility
over... but I'm preaching to the choir here.

So in worst case scenario where an HTTP client has run
into a Server using buggy filters that can't seem to send error 
pages then just set the error code, ZERO the body, and let the header
go back. If it's any kind of compliant user-agent at all then it
will probably have its OWN error page that is going to show
up so you are still covered ( Most people do, in fact, use new
MSIE local error pages which replace anything Apache is
sending, anyway ).

Okay... so what about NON-HTTP Clients like WML browsers?

Well... if you want to go the full Monty and assume that Apache
is able to act as a true WML gateway then there is, in fact,
an issue which may or may not need to be covered in the design.

There is no such thing as text/plain in the WML world.
The page HAS to be formatted as as DECK/CARD or it's
going to be rejected by any modern WML browser.

If the 'filter' that has coughed up at runtime is, in fact, the
HTML to WML filter then things get a little schizophrenic.

You can't just send the 'canned' HTML. It won't work.
You can't just send 'text\plain'... that won't work either.
Somebody HAS to put the WML headers/footers around
that canned response or you might as well not send it.

I can't possibly imagine someone writing an HTML to WML
filter that could ever possibly be so broken that it couldn't
simply convert a simple HTML error page to WML DECK/CARD
format... but it's possible.

All this means is that the filtering engine MIGHT have to know
when something has happened which makes it either impossible
or impractical to send back ANY kind of 'canned response' at all.

>  We are talking about the canned error messages.  

I know. See above. Non-HTTP clients are the ones that have
to be accomodated.

> Those are the messages associated with 3xx, 4xx, and 5xx error
> codes.  Do we really think that required filters will be generating those
> error codes?  

It depends. It's really up to you, the designer.

The WML and WAP error codes don't match the HTTP ones, anyway.

What if a WAP filter dishes up the equivalent of the HTTP 'Internal
Server error'? Do you want the filter designer to use the 'canned'
HTTP messages in Apache or require that he provide ALL of his/her
own error pages for ALL of the possible errors?

If you let them use the equivalent HTTP pages ( which explain the
problem just fine ) then the issue of whether YOUR HTML must
still be 'converted' remains.

> I don't know, which is why I am asking.  I am trying to
> envision a case where an HTML to WML filter will be generating those error
> codes, and I'm not seeing it.

Grab an SDK and a WAP emulator for your desktop and just write
1 simple 'Hello World' WML page and I think you will immediately
understand the issues. You will be shocked at how STUPID WML
really is. Anything that is promising to be a WML Gateway has 
issues that normal HTTP Server don't have. In some cases, 
sending just text\plain can actually CRASH the WebPhone or PDA.
>  Also, if we look at ap_die, there is already logic to ensure that we don't
>  recurse infinitely.  Can we use the same general logic for filters?

ap_die normally just sends a 'canned' and bails.

If those 'canneds' from ap_die are now supposed to always
float back through the same processing path that generated
the error in the first place then I still think you are looking
at a possible infinite loop in some cases.

Unless you set a 'flag' which says 'Attention: This generated
content is coming from ap_die()... don't touch it' ???

It's complicted. how do you promise that ALL output from
Apache will be filtered at all times when the very thing that
Apache might want to 'say' can't pass through the very thing
that is causing the error? Sometimes you just have to PUNT.

In the case of an HTTP client... just send the 'canned'.

In the case of a WAP/WML client... ask the filter if it can
send the equivalent HTTP error code and if it can't... all you
can do is close the connection.

Maybe requiring filters to have an 'error' handler themselves
is the answer. This would be the part of a filter that
ALWAYS has to work. The only time it kicks in is if the
content to be filtered is KNOWN to be one of the canned
error messages floating out the door. That way, something can
belly up in the main HTML to WML filter but it should STILL be
able to convert the error page to WML so the WAP browser user
knows what the heck happened.

Picture this...

At the very least the filter's ERROR handler could simply be
sure that the document going out the door says SOMETHING
even if it can't translate the HTTP error to WAP equivalent.

Palm Computing's Online Server is a good example.
Their PQA client applications are 'pretending' to be HTTP 
compliant but are no such thing. They 'supposedly' let
you write your PQA using HTML but when the Server
gets that HTML and finds something wrong with it you
will NEVER get back the right HTTP error code. All you
ever get is 'C0020000 Document Error'... but at least
you always get SOMETHING.

An HTML to WML filter for Apache should at least be
able to do the same thing. If it can't translate the 
canned error then at least send back SOMETHING.

One more example:

Say the problem occurs BEFORE content. That is... Apache
itself has received a header NO-NO and is immediately trying to
generate a canned response such as an HTTP 1.1 GET
request showing up with no Host: field ( required ).

The filters should STILL kick in and try and send the right
interpretation of that 'Bad Request' error for the User-Agent.

Actually this brings up another can of worms since there is no
sense in anyone trying to write an HTML to WML filter unless
Apache itself is capable of receiving WML requests and the 
filtering itself gets a chance to determine what is or is not 
valid in the request header but if the filtering itself is there then 
adding that capability won't be too big of a deal.

Not sure you fully grasp the mess that is WAP and WML which 
is usually using standard port 80 but is not, actually, HTTP at all. 
It just 'imitates' HTTP and doesn't even do that very well.
If that isn't a can of worms itself then I don't know what is.

Kevin Kiley
http://www.Remote Communications, Inc - Online Internet Content Compression Server.

View raw message