Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33513
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <474F23D4.8060306@lerdorf.com>
Date: Fri, 30 Nov 2007 06:40:52 +1000
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>
CC: internals@lists.php.net
References: <28.76.32949.5211F474@pb1.pair.com>
In-Reply-To: <28.76.32949.5211F474@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposed feature for json_encode()
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Sara Golemon wrote:
> While it's technically "safe" to include user supplied data in
> json_encode() serialized values.  The fact that characters such as <>&'
> remain as is means there room for some as-yet unidentified problem
> either in the browser's rendering or (more likely) elsewhere in one's
> codebase for this data to get into the wrong context and be executed.
> 
> To that end, the attached patch allows the caller to be paranoid about
> their data and stipulate that <>&' should be encoded to hex references
> instead.  This doesn't stop a web developer from dropping that content
> into an innerHTML of course, but it's one more rope holding the ship
> together.
> 
> Obviously, since this adds five characters per pedantically escaped
> character, it's not something you'd want on by default, so the normal
> behavior would be to leave them alone.
> 
> echo json_encode("<foo>");
> "<foo>"
> 
> echo json_encode("<foo>", JSON_HEX_TAG);
> "\u003Cfoo\u003E"
> 
> echo json_encode("<foo bar='baz'>", JSON_HEX_TAG | JSON_HEX_APOS);
> "\u003Cfoo bar=\u0027baz\u0027\u003E"

This was on my TODO, but you are way more productive than I am as
witnessed by the 3 copies of this proposal we got.  ;)

-Rasmus