Re: json_encode() behavior for incorrectly encoded strings

On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > >> The warning for invalid UTF-8 stays intact and is thrown also with >> display_errors = On. If this behavior is undesired this can be remedied >> later. > > Must we discuss it 1000 times anew? There was a reason why it didn't > throw warning when display_errors is on. The reason is that it is very > easy to feed the server configured with display_errors = on wrong JSON > and thus force it to reveal information, and this is largely beyond the > control of application writer. Yes, I feel like we must discuss this a thousand times anew. There clearly is no consensus about it. Just look at the responses in this thread and in other discussions relating this issue. When people read "throws a warning, but only if display_errors=Off" they automatically replace the Off with an On in their mind. The behavior is simply that unintuitive. Also I'd like to point out that we already decided to *not* use this behavior in other, similar situations. E.g. max_input_vars throws regardless of display_errors (and yes, this was discussed when the feature was introduced). In any case, I don't care *that* much about how json_encode behaves, so I'd be fine with either way. Would just be nice if someone could tell me what that "way" should be. I didn't see any consensus in the discussion. > But what I am worried about even more is getting back to that "commit > first, discuss later" mentality. Why we have again a commit in the > stable branch before we have a consensus decision what it should be doing? I only wanted to sync the branches up. I didn't consider the warning such an important aspect of this issue and thought that it would be okay to simply adjust it in a separate commit. Nikita