Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68484 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21421 invoked from network); 11 Aug 2013 03:24:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Aug 2013 03:24:13 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.215.47 mail-la0-f47.google.com Received: from [209.85.215.47] ([209.85.215.47:51968] helo=mail-la0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 81/76-06453-CD307025 for ; Sat, 10 Aug 2013 23:24:13 -0400 Received: by mail-la0-f47.google.com with SMTP id eo20so3828465lab.6 for ; Sat, 10 Aug 2013 20:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SwCTdKRdr/orDLcVkrwxwg0dza+VtSaFCtNoPJaXySA=; b=BNJXT5lpfuKA4MxPo0QN1kbQONiJb0HcmETmS8bBq/FnsGIEytL/Nw35udeQmmVhyh C1yhb7zhnkgJ/9+JAKVNXBkC7ccwpMXvaB0f0ngJap/Gso91suXutiJxOtfltRyCPDIF d49yufq5NG6CbLYKD4pkvF5NnF3SX8MA6rSc7mA0xVUHZR/wR6T3ZcVlj5zh3JaExW1d cCZqaPcX5EbcNqyr9eoiAr9BmqvS2S7/LBRbamzANd08COD7kpedNBLsTd/n14QdbJoO 1ySMWAk1IRgASLzkU7ohSSewC3Ri/LdpFSag4/ykpqXxTbQyMIO78TqDgpSStq3Cm8tN 5ojg== X-Received: by 10.112.29.17 with SMTP id f17mr2867770lbh.45.1376191449972; Sat, 10 Aug 2013 20:24:09 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.127.233 with HTTP; Sat, 10 Aug 2013 20:23:29 -0700 (PDT) In-Reply-To: <5206C4BA.80502@sugarcrm.com> References: <52035622.1090301@lsces.co.uk> <52038ABF.8060904@lsces.co.uk> <5204B690.4060006@lsces.co.uk> <52051E71.9010309@sugarcrm.com> <5206C4BA.80502@sugarcrm.com> Date: Sun, 11 Aug 2013 12:23:29 +0900 X-Google-Sender-Auth: GG1s6UuAL5dJo8q5K_13HxUIHPQ Message-ID: To: Stas Malyshev Cc: PHP internals Content-Type: multipart/alternative; boundary=001a1133c69084c8a504e3a38adc Subject: Re: [PHP-DEV] "php_serialize" session serialize handler From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1133c69084c8a504e3a38adc Content-Type: text/plain; charset=UTF-8 Hi Stas, On Sun, Aug 11, 2013 at 7:54 AM, Stas Malyshev wrote: > > > - Session fails to save if it contains special chars > > Session data or session variable names? If the former, it is a strange > bug but certainly needs fixing. If it's the latter, it is the same > exotic issue, which I suspect very small number of people actually have. > Still, I'm ok with adding option to support them, as long as it does not > make problems for the majority. > IIRC. It is name. > - Want unserialize session from session data, not from $_SESSION > > - Need function generates initial session data via dession_decode > > These functions can be added without changing session format, but the > mere existence of these requests shows us that > > > - Session should use plain serialize > > This is not a valid request, there's nothing mandating session using > plain serialize. > This kind of request were closed as bogus/won't fix since there were register_globals. We can make the serializer, but it's not worth it due to the limitations at least for me. > > > We don't want to keep misdesigned component due to "register_globals", > > don't we? Especially when the solution does not have real BC issue. > > We're walking in circles here. I have a number of times existence of the > BC issue, yet you plainly dismiss it as "not real", and continue to talk > about register_globals, which has nothing to do with it. So, to not > prolong pointless discussion, here's my opinion: > 1. Adding php_serializer option for session is fine for 5.5, please make > a pull req for it. > 2. Making it default - as long as it is not backwards-compatible - is > not OK, at least before PHP 6. If you feel strongly that it must be > done, the vote must be held on this subject since this change has BC > implications. > > With this, I think I'm done discussing this subject. > OK. I'm fine with this, I'll send PR later with tests. I still don't understand why we should care so much, instead of removing "some error occurred in some file line 0", though. Anyway, this would be end of discussion and I'm glad that I can close some of bugs/requests assigned to me. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1133c69084c8a504e3a38adc--