RFC: Error handling in HTTP input decoding

I'd like to solicit opinions on how we should treat conversion failures 
during HTTP input decoding. There are two issues at hand: fallback 
mechanism and application-driven decoding in case of failure. Let's 
look at the proposal for the latter one first.

If the decoding of HTTP input fails (and the failure state would be 
achieved as soon as even one variable fails), PHP should set an error 
flag somewhere that is accessible to the user, via either a global 
variable or a function. It should also keep the original request data 
around (query string, POST body, and cookie data). The application 
should be able to access this data, since the encoding can be passed in 
the query string [1]. The application can then check this error flag 
and then call a function -- request_decode() perhaps -- to ask PHP to 
re-decode the request data based on a this specific encoding. For 
example:

   if (request_decoding_failed()) {
      request_decode(request_get_raw('ei'));
   }

We might be able to tie this in with the input filter, but that means 
that the input filter will have to be required by PHP. I am open to 
other suggestions in this area.

As for the first issue, PHP attempts to decode the input using the 
value of the unicode.output_encoding setting, because that is the most 
logical choice if we assume that the clients send the data back in the 
encoding that the page with the form was in. We could implement a 
fallback mechanism where PHP looks at the Accept-Charset header sent by 
the client[2]. This header is supposed to indicate what character sets 
are acceptable for the response. While this is not the same as 
specifying the character set of the request, it might be a good enough 
indicator of it. Or we could simply set the error state and let 
application figure out what charset it wants to use for decoding.

Thanks for your attention.

-Andrei

[1] http://search.yahoo.com/search?ei=UTF-8&p=php
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html