Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69759 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2196 invoked from network); 22 Oct 2013 11:10:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2013 11:10:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=bof@bof.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bof@bof.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender) X-PHP-List-Original-Sender: bof@bof.de X-Host-Fingerprint: 80.242.145.70 mars.intermailgate.com Received: from [80.242.145.70] ([80.242.145.70:58116] helo=mars.intermailgate.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B2/90-10840-22D56625 for ; Tue, 22 Oct 2013 07:10:28 -0400 Received: (qmail 30849 invoked by uid 1009); 22 Oct 2013 13:10:23 +0200 Received: from 209.85.212.49 by mars (envelope-from , uid 89) with qmail-scanner-1.25-st-qms (clamdscan: 0.96.2/17988. spamassassin: 3.3.1. perlscan: 1.25-st-qms. Clear:RC:1(209.85.212.49):. Processed in 0.082367 secs); 22 Oct 2013 11:10:23 -0000 X-Antivirus-MYDOMAIN-Mail-From: bof@bof.de via mars X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:1(209.85.212.49):. Processed in 0.082367 secs Process 30835) Received: from mail-vb0-f49.google.com (gmail@bof.de@209.85.212.49) by mars.intermailgate.com with RC4-SHA encrypted SMTP; 22 Oct 2013 13:10:23 +0200 Received: by mail-vb0-f49.google.com with SMTP id w16so4812040vbb.22 for ; Tue, 22 Oct 2013 04:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eNj9mJFK8gsRe4UADMxi6kqNfTAVCfharDLjoPR+SpU=; b=VN5Uj4I/bly9FATojK+mI+gynvkir/32PGQSJtPLVHt+VoO3EXKYkIKSgKYt1xSwL/ twIfauWMByJUrw2v3lKRYFR6Z2d7hYJErSufiPNnoC0ZYYWHdJd6nIVx3+3YPPu9hwtA /Q36+2ZDpd+KkifIkwhIGlAjD969ZwHUA1aRYTMkA1kYBsl9TVhL5VAakaJTZWp1vFSD 6KyUgGb+AUABPs9E9GJRyF+8JquOaPMCkzHdJOl07p/tmMAKPc+Wp/ZlNgfkW98DXWOJ 7IrFHk25CDu8yNLCgcAEcnIx2JJzqTeG82eQyhG5dqhMM60WQy87OO8NRzaNtgw0anB9 GYrw== MIME-Version: 1.0 X-Received: by 10.220.11.7 with SMTP id r7mr14756653vcr.12.1382440221731; Tue, 22 Oct 2013 04:10:21 -0700 (PDT) Received: by 10.52.185.102 with HTTP; Tue, 22 Oct 2013 04:10:21 -0700 (PDT) Received: by 10.52.185.102 with HTTP; Tue, 22 Oct 2013 04:10:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Oct 2013 13:10:21 +0200 Message-ID: To: Ferenc Kovacs Cc: internals , Yasuo Ohgaki Content-Type: multipart/alternative; boundary=001a11c3e47c57082704e9527235 Subject: Re: [PHP-DEV] session_regenerate_id(true) by default From: bof@bof.de (Patrick Schaaf) --001a11c3e47c57082704e9527235 Content-Type: text/plain; charset=ISO-8859-1 Am 22.10.2013 12:48 schrieb "Ferenc Kovacs" : > We could we add an E_DEPRECATED for the session_regenerate_id(false) usage > for 5.6 instead. I might find that useful for the session_regenerate_id() case, i.e. when using the default, but IMHO there are perfectly valid reasons to keep the previous session active in a controlled way. Working on the issue for our own application, I'm in the process of teaching our session wrapping class to regenerate ID often - but when doing so, first setting up the previous session ID with two pieces of information: a short timeout of 20 seconds or something like that, and a "forwarding ID" which references the new session ID. I want to do this because I want to regenerate IDs often (also based on a rather short timeout), and I'm concerned about parallel in-flight requests - a high probability reality with ajax getting more and more traction - still presenting the old session ID a second or two after a request determined to regenerate. BTW and a bit off-topic: is there a good reason for session_write_close not returning a success indicator? Right now it spams the log with a misleading message, but gives me no chance (short of setting up a global error handler to catch and handle that message) to see (and maybe retry / use a fallback) on failure best regards Patrick --001a11c3e47c57082704e9527235--