Newsgroups: php.i18n,php.internals
Path: news.php.net
Xref: news.php.net php.i18n:1013 php.internals:24182
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: <Jared.Williams1@ntlworld.com>
To: "'Andrei Zmievski'" <andrei@gravitonic.com>,
	"'PHP Internals'" <internals@lists.php.net>
Cc: "'PHP I18N'" <php-i18n@lists.php.net>
Date: Fri, 23 Jun 2006 01:11:06 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <8d4744f0dfe707de33fb151f714bec00@gravitonic.com>
Thread-Index: AcaWSEXUp3XlvTMuT/GBe+rD6qhaXwAEG2Yg
Message-ID: <20060623001047.KWCQ16286.aamtaout03-winn.ispmail.ntl.com@win2ks>
Subject: RE: [PHP-DEV] RFC: Error handling in HTTP input decoding
From: jared.williams1@ntlworld.com ("Jared Williams")
References: <8d4744f0dfe707de33fb151f714bec00@gravitonic.com>

 

> -----Original Message-----
> From: Andrei Zmievski [mailto:andrei@gravitonic.com] 
> Sent: 22 June 2006 22:46
> To: PHP Internals
> Cc: PHP I18N
> Subject: [PHP-DEV] 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 

https://bugzilla.mozilla.org/show_bug.cgi?id=18643

Maybe of interest, it's the kludge for determining form charsets, after the
charset in the Content-Type header broke too much.

> 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
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>