Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28346
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 66.249.92.168 as permitted sender)
DomainKey-Status: bad
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=JwconB0nL+F/3raCrlca4WvLaeWNVeWgQbYERnEZ+ia2vPunxnEgJIj/30oZrtYWqCfKu9ZkpemUillqbvqU6gFAo5cMtpfF5G0Xrcn46bAPH0eZJNJ2S1AM/l2lF4ILR+fORaXkKI8eqrfkOsuY93gPO8K25RTJNRRMu3zhjkQ=
Message-ID: <10845a340703150546y114fb9eekc74dc3b32ab9394e@mail.gmail.com>
Date: Thu, 15 Mar 2007 12:46:40 +0000
Reply-To: RQuadling@GoogleMail.com
To: "Stefan Esser" <sesser@hardened-php.net>, 
	"Markus Fischer" <markus@fischer.name>
Cc: internals <internals@lists.php.net>
In-Reply-To: <10845a340703150522x28ac5a04xa55fb612c04e7767@mail.gmail.com>
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>
	 <10845a340703150522x28ac5a04xa55fb612c04e7767@mail.gmail.com>
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")

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 <rquadling@googlemail.com> 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.
>
> <?php
> 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 <sesser@hardened-php.net> 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.
> > >
> > > <?php
> > > 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 <a href="' .
> > > MakeWebPath(realpath($s_PDFReport)) . '">here</a>.');
> > > 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!"