Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28345 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24652 invoked by uid 1010); 15 Mar 2007 12:22:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 24637 invoked from network); 15 Mar 2007 12:22:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2007 12:22:33 -0000 Authentication-Results: pb1.pair.com header.from=rquadling@googlemail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=rquadling@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 66.249.92.175 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@googlemail.com X-Host-Fingerprint: 66.249.92.175 ug-out-1314.google.com Linux 2.4/2.6 Received: from [66.249.92.175] ([66.249.92.175:18700] helo=ug-out-1314.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A3/8C-24282-68A39F54 for ; Thu, 15 Mar 2007 07:22:32 -0500 Received: by ug-out-1314.google.com with SMTP id o4so327326uge for ; Thu, 15 Mar 2007 05:22:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q57TroBC/qzkZ3eV1k0RwVUc9DhcYXsbedD238R3hLkRXYAMTls4pkz7YC3LpRaGtQUc9R0wc8MaUzx4Zmsf4jMkX9LKjUDhFX7OHfc7Fl7TojYElu5a5MopvpcJy3/ADxkZWzdbBMwp5uj/e7CRvx2VYvqHlVtupzqdzXqmMVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pRSKgRFgAzOi3+6an32v1e5lvzUms2+ZkGP04rPe+9miALn0fKLi0yxDsvwHezI2zyO9h1F389yL6iMNuVa4x/GZVKc5TQ7CpAW1M1RcbVgYSKHm0cmNGFCJp0d59KMH1Grdeq9hO/jHx26Vil9nRtoQF41ANFYYXhw7Xs8dGPM= Received: by 10.78.157.8 with SMTP id f8mr316812hue.1173961344334; Thu, 15 Mar 2007 05:22:24 -0700 (PDT) Received: by 10.78.48.5 with HTTP; Thu, 15 Mar 2007 05:22:24 -0700 (PDT) Message-ID: <10845a340703150522x28ac5a04xa55fb612c04e7767@mail.gmail.com> Date: Thu, 15 Mar 2007 12:22:24 +0000 Reply-To: RQuadling@GoogleMail.com To: "Stefan Esser" , "Markus Fischer" Cc: internals In-Reply-To: <45F9381F.3040708@hardened-php.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10845a340703140437q519bd232sc9b7dca53cef1e91@mail.gmail.com> <45F9381F.3040708@hardened-php.net> Subject: Re: [PHP-DEV] A request for code change : Repeated opening and closing the session leads to a LOT of Set-Cookie headers. From: rquadling@googlemail.com ("Richard Quadling") Hmm. Good idea! I think I also have to turn off session.use_only_cookies. I just tried this, but within the framework the ini_set return false (when the value is currently "1") and the setting was not altered and I've yet to work out why. In a simple test this works fine. On 15/03/07, Stefan Esser wrote: > Hello Richard, > > your problem is a bug in the session extension. > > My suggested but not tested workaround is that you simply call > > ini_set("session.use_cookies", 0); > > after the first time you call session_write_close(). This will stop the > session extension from sending further cookies during a single request. > > Stefan Esser > > Richard Quadling schrieb: > > Hi. > > > > I have a webapp which uses Ajax to initiate a process on the server > > which could take several minutes to complete and will go through many > > steps to before the task is finished. > > > > In that script, I update the session to indicate the current position > > of the process. > > > > When the user initiates the main process, another AJAX request is made > > which examines the state of the main process (via the session) and > > reports back to the client - keeps them interested. The user can also > > abort the process and closing the browser also triggers an abort. > > > > All works FINE in FF. In IE, I'm getting a "Page cannot be displayed" > > sort of errror (having to debug the response to see this). This SEEMS > > to relate to the fact that I am closing and opening the session in the > > first script as I want to keep the session file uptodate. The process > > script only has 1 output and that is the final result at the end of > > the script. > > > > I also tested this using a telnet connection to the webserver and sent > > the same headers that FireFox generated (captured via FireBub) and it > > bombed just before the data arrived (Lost connection). > > > > e.g. > > > > > function UpdateSession($s_Progress) { > > session_start(); > > $_SESSION['Progress'] = $s_Progress; > > session_write_close(); > > } > > > > //Stage 1 > > UpdateSession('Loading preferences'); > > ... > > //Stage 10 > > UpdateSession('Report generated and is now available at here.'); > > echo rawurlencode(json_encode(array('SUCCESS' => > > MakeWebPath(realpath($s_PDFReport))))); > > ?> > > > > > > As a consequence, I get ... > > > > Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/ > > Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/ > > Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/ > > ... > > > > LOTS of times followed by a "Page cannot be displayed". If I use > > Ethereal to examine the data, it is all there and is the same via IE > > and FF, it is just the IE doesn't like the REALLY long header. > > > > I accept this is normal behaviour and IE should "deal with it", but ... > > > > Is there any mileage in stopping session_start from sending the same > > header if it has already been sent? If the PHPSESSID is different, > > then fine, send it. > > > >> From looking at session.c and php_session.h, I think the following > > changes would suffice. > > > > 1 - The typedef struct _php_ps_globals {} needs to include ... > > > > char *prev_id; > > > > > > 2 - In PHP_GINIT_FUNCTION(ps) ... > > > > ps_globals->prev_id = NULL; > > > > > > 3 - In php_session_send_cookie(TSRMLS_D), do a comparison of prev_id > > and id (taking into account prev_id could be NULL) and if different, > > then allow the cookie to be set and to update prev_id with the id > > sent. > > > > > > Some other issues, if other parts of the cookie are altered, then > > maybe rather than just examining the ID, the entire cookie should be > > remembered. > > > > > > Assuming that the cookie would be identical, repeatedly sending it to > > the client when the session is repeatedly opened is a pain and I think > > can easily be fixed. > > > > > > Thank you for your time. > > > > Richard Quadling. > > > > > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"