Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69763
Return-Path: <derick@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 16811 invoked from network); 22 Oct 2013 12:23:02 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 22 Oct 2013 12:23:02 -0000
Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
X-PHP-List-Original-Sender: derick@php.net
X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6
Received: from [82.113.146.227] ([82.113.146.227:57429] helo=xdebug.org)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 98/33-10840-52E66625 for <internals@lists.php.net>; Tue, 22 Oct 2013 08:23:02 -0400
Received: from localhost (localhost [IPv6:::1])
	by xdebug.org (Postfix) with ESMTPS id 8220BE202D;
	Tue, 22 Oct 2013 13:22:58 +0100 (BST)
Date: Tue, 22 Oct 2013 13:22:58 +0100 (BST)
X-X-Sender: derick@whisky.home.derickrethans.nl
To: Patrick Schaaf <bof@bof.de>
cc: Ferenc Kovacs <tyra3l@gmail.com>, internals <internals@lists.php.net>, 
    Yasuo Ohgaki <yohgaki@ohgaki.net>
In-Reply-To: <CAJ26g5QH4j3K2peF7rGO-2uO_mjBK4kQELXCBQVXJOe9A7UEsw@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1310221322020.5542@whisky.home.derickrethans.nl>
References: <CAGa2bXbNFb0tV+Xqavz9m62RDxobey3BmyN0L7g9ATFxMS_KBA@mail.gmail.com> <CAH-PCH7TbexgCAVphaC_H8AF-V5UfNysy863Gq1sOzkxgQ01XA@mail.gmail.com> <CAJ26g5QH4j3K2peF7rGO-2uO_mjBK4kQELXCBQVXJOe9A7UEsw@mail.gmail.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] session_regenerate_id(true) by default
From: derick@php.net (Derick Rethans)

On Tue, 22 Oct 2013, Patrick Schaaf wrote:

> 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

It's likely because the utility function that throws the warning is also 
called during request shutdown, where you can not really show errors 
anymore. Logging errors is still fine at that stage.

cheers,
Derick