Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63167
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
References: <CAO1hux8mmUsy4badiNjxTGMubaduD1gkgbw4ZK1Me_MwGwLybA@mail.gmail.com> <CALtuQzC4e2Sn_BHinFAPdVrz8Oc_d6wCqTr=AscMChH29NSENw@mail.gmail.com> <CAO1hux9+4QK2sVX9+4110ksa9qDpUpfDhFJvyzkXcBHrFoFWvg@mail.gmail.com> <0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com> <CAO1hux9t9refYHYnKhY0725MvRm88ab85Ng23LCvnjDJxqQA7g@mail.gmail.com> <CALwr1GnjjjMbK8-VkVO57meDAgDn8PSPoWdj2DjYMB7F01dP4Q@mail.gmail.com> <CAPwsocGs=5-JfpSSewDRaNC0KaoNF1okBD8-E27fx5U=9f6sgw@mail.gmail.com> <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com> <CALwr1GmhT5X4eqPwhOtMuj_C37bxDZ2tHnrzm9JyqUo19tu7pw@mail.gmail.com>
In-Reply-To: <CALwr1GmhT5X4eqPwhOtMuj_C37bxDZ2tHnrzm9JyqUo19tu7pw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-ID: <5B535BBE-3F7F-44A5-82AF-576B7EC6D770@gmail.com>
Cc: Leigh <leight@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Date: Wed, 19 Sep 2012 11:07:43 -0700
To: =?utf-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>
Subject: Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
From: mike503@gmail.com (Michael Shadle)


On Sep 19, 2012, at 10:55 AM, P=C3=A1draic Brady <padraic.brady@gmail.com> w=
rote:

> I have never once expressed a problem with this being a set of
> procedural function. Not once. The RFC offers some suggested function
> signatures. So nobody has expressed any issues and nobody has insisted
> that you be required to use a class or object.

Sorry; it just felt like the conversation was getting so heavy on syntax tha=
t people would be viewing the only way to implement the functionality would b=
e requiring an OO interface to it. Look at all of the examples people post s=
o far :)

> The RFC addresses escaping, not input filtering. Yes, there is a fine
> line between them but the filter method requires constants, options,
> and we would then need to later in character encoding. The resulting
> mutation would be a step backwards in my opinion in guiding users
> towards the secure use of escaping in applications.

I brought up the filter functions as an example of semantics/syntax. Not fun=
ctionality. I understand and agree with them being separate.

> Correct encoding is essential. The entire planet does not use UTF-8,
> and UTF-8 is not the same as other encodings once you get over the
> theoretical perfection that should exist and meet the rebels:
> browsers. Please bear in mind that using the correct encoding has been
> preached for many many years as a minimum requirement in secure
> escaping for PHP.

As mentioned before I removed my discussion point about encoding. It was jus=
t an idea. I think it should be UTF8 by default but accept encoding as a par=
ameter.

I think we are probably on the same page here. I have not looked at the RFC b=
ut was just seeing floods of example code coming through the mailing list an=
d started being vocal based on my concerns from that. An RFC doesn't mean it=
 will happen exactly as the RFC defines it :)