Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28364 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3272 invoked by uid 1010); 16 Mar 2007 01:20:07 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 3257 invoked from network); 16 Mar 2007 01:20:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2007 01:20:07 -0000 X-Host-Fingerprint: 213.65.235.2 213-65-235-2-o259.telia.com Received: from [213.65.235.2] ([213.65.235.2:18624] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 62/39-19476-4C0F9F54 for ; Thu, 15 Mar 2007 20:20:05 -0500 Message-ID: <62.39.19476.4C0F9F54@pb1.pair.com> To: internals@lists.php.net References: <10845a340703140437q519bd232sc9b7dca53cef1e91@mail.gmail.com> <45F9381F.3040708@hardened-php.net> <10845a340703150522x28ac5a04xa55fb612c04e7767@mail.gmail.com> <10845a340703150546y114fb9eekc74dc3b32ab9394e@mail.gmail.com> Date: Fri, 16 Mar 2007 02:20:14 +0100 Lines: 177 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-RFC2646: Format=Flowed; Response X-Posted-By: 213.65.235.2 Subject: Re: [PHP-DEV] A request for code change : Repeated opening and closing the session leads to a LOT of Set-Cookie headers. From: dvdmandt@telia.com ("David Lindstrom") Well, you could always add a user comment. Isn't that what they are for anyway? ""Richard Quadling"" skrev i meddelandet news:10845a340703150546y114fb9eekc74dc3b32ab9394e@mail.gmail.com... > Ha! > > Stupido! I had cut'n'pasted and somehow had a trailing space on the > ini entry name! > > But, it works a treat. > > Is this worth mentioning in the dox? I have karma there, but I don't > want to add just because I can. > > > > On 15/03/07, Richard Quadling wrote: >> 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. >> >> > for($i = 0 ; $i < 246; ++$i) // 245 counts are OK, 246 are not. >> { >> session_start(); >> $_SESSION['Count'] = $i; >> session_write_close(); >> // ini_set("session.use_cookies", 0); // Removing the comment here >> and >> upping the count above worked fine. >> } >> var_dump($_SESSION); >> ?> >> >> 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!" >> > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!"