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