Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34937
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.174 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id;
        b=EzPX0GvYTTaxCIYOAqKhhzrkqcHqwr+0t571rU1j1Ylj+J6VlPVu4GluFu+tYtUOQ/ZQlgiutydy+o2grF5Hu72R1kQSs1FAYbgOqZjkCGlJkgIJzHI1bqoJPBEVXJGjjx40t2e5nQ9i9WlOUlv6FMHPV5DuKJ+cpFT6znKFemw=
To: Stanislav Malyshev <stas@zend.com>
Date: Sat, 26 Jan 2008 12:47:53 +0100
User-Agent: KMail/1.9.7
Cc: internals Mailing List <internals@lists.php.net>
References: <200801241426.39756.arnaud.lb@gmail.com> <479A613C.8030604@zend.com>
In-Reply-To: <479A613C.8030604@zend.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200801261247.53115.arnaud.lb@gmail.com>
Subject: Re: [PHP-DEV] [PATCH] Bug #43896 htmlspecialchars returns empty string on invalid unicode sequence
From: arnaud.lb@gmail.com ("Arnaud.lb")

> > Should really theses functions discard the whole string for a single 
> > incomplete sequence ?
> 
> I think since it is not possible to recover true content of the string, 
> it is ok to return failure value. Cutting it in random places or 
> ignoring problems doesn't seem a good idea - it might lead to all kinds 
> of nasty things, such as security filtering checking one data and 
> database getting entirely different data.

I dont think so. htmlspecialchars' job is to replace character sequences which 
may be interpreted as HTML special characters by the browser. Its job is not 
to validate a string or to check if it will be passed correctly to a DB.

htmlspecialchars with my patch just achieves that.

There are many chances to have an invalid unicode sequence in a user input. In 
normal situations, text typed in a form element will be sent in the correct 
encoding by the browser, but what about file uploads ? What if the browser 
itself send invalid sequences ? (e.g. copy/paste of word documents in a form 
and/or wysiwyg-enabled elements using IE). Bugs 43896, 43294 and 43549 also 
report theses problems.

This new htmlspecialchars version will be a nightmare for many php users if it 
is left as is.