Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28342
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 66.249.92.171 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:references;
        b=NYHD/L87ARgXHWYLTt8u9XPSW9ukp2VzlYejmhDoMFKttJtDVlcWxnSdueJ57eqL+Mm8zfCUFT+itIIw2Oj3YxE3Nn2JdwU4FfocLTiNSGDLbMSFKud7LRLarKYfG/VHtVfTluZpcdrIvnU7WpyURBlqr8ESAokjMLf3gitYYV0=
Message-ID: <10845a340703150215v1dfe329ev8aaff25e3fcb5cbf@mail.gmail.com>
Date: Thu, 15 Mar 2007 09:15:46 +0000
Reply-To: RQuadling@GoogleMail.com
To: "Markus Fischer" <markus@fischer.name>
Cc: internals <internals@lists.php.net>
In-Reply-To: <45F84785.9030304@fischer.name>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_54674_3193325.1173950146249"
References: <10845a340703140437q519bd232sc9b7dca53cef1e91@mail.gmail.com>
	 <45F84785.9030304@fischer.name>
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")

------=_Part_54674_3193325.1173950146249
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello Markus and thank you for your comments.

I feel there are 2 things to be considered with your suggestion.

1 - It doesn't matter what the server side handler is
(files/user/sqlite/mm/etc), session data is not stored until you do a
session_write_close(). So for a separate process to have access to the
data, the session must be closed.

2 - For the main process to update the session, a session_start() is
required which generates the Set-Cookie header.

Sessions DO work nearly perfectly with the main process updating by
opening/closing and with the helper processes reading the status and
maybe updating the abort flag. It is just the superfluous Set-Cookie
headers and IE being crap.

Fixing php_session_send_cookie() to compare a previously saved header
with the one about to be sent shouldn't have a huge impact on the
majority of code and would seem to fix the problem.

I've attached a patch which I hope is more or less there.

I see this as an easy fix with possible a miniscule performance
increase as the header won't need to be sent when it is not needed.
OOI. It may be a better solution to detect duplicate headers in the
sapi_add_header_ex() function. Maybe.

I suspect though that the entire cookie needs to be compared (PS
should contain a smart_str prev_cookie rather than char *prev_id sort
of thing), but I'm not that good at the PHP's macros and without a
compiler I'm guessing.

I see that the v1.360 of session.c (Line 982) introduced this "issue"
by not replacing the cookie. So this has been around for a while.

Please add this little patch as it will mean AJAX with IE and PHP
sessions will all play nicely with each other and there is no need to
add additional userland code to deal with locking as PHP sessions do
EXACTLY what is required.

Regards,

Richard Quadling.



On 14/03/07, Markus Fischer <markus@fischer.name> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Richard,
>
> before starting hacking the source, what do you think about using
> session_set_save_handler() to specify your own custom session handlers
> which write your session into a database and not on the file system?
>
> I think this way, once you know the session id (which you do after the
> first time you call session_start), you can simply update the
> information in the database directly on your own without calling
> session_start()/sesion_write_close() numerous times. Probably you need
> to take care about locking on your own, but with a database that
> shouldn't be too hard.
>
> HTH,
> - - Markus
>
> Richard Quadling wrote:
> > 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.
> >
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF+EeF1nS0RcInK9ARAv+4AJ0U9vghOlKO5rIyxh3CmYDDXOe8zwCfXPOn
> 3EQjSg8mMEgVQVpiLwMBja4=
> =+5S8
> -----END PGP SIGNATURE-----
>


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

------=_Part_54674_3193325.1173950146249
Content-Type: text/plain; name=session.diff.txt; charset=ANSI_X3.4-1968
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ezaytq24
Content-Disposition: attachment; filename="session.diff.txt"

SW5kZXg6IHBocF9zZXNzaW9uLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9zaXRvcnkvcGhw
LXNyYy9leHQvc2Vzc2lvbi9waHBfc2Vzc2lvbi5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEx
MwpkaWZmIC11IC1yMS4xMTMgcGhwX3Nlc3Npb24uaAotLS0gcGhwX3Nlc3Npb24uaAk1IEphbiAy
MDA3IDAzOjU3OjU3IC0wMDAwCTEuMTEzCisrKyBwaHBfc2Vzc2lvbi5oCTE1IE1hciAyMDA3IDA4
OjQ3OjUwIC0wMDAwCkBAIC0xMzIsNiArMTMyLDEwIEBACiAJaW50IHNlbmRfY29va2llOwogCWlu
dCBkZWZpbmVfc2lkOwogCXplbmRfYm9vbCBpbnZhbGlkX3Nlc3Npb25faWQ7CS8qIGFsbG93cyB0
aGUgZHJpdmVyIHRvIHJlcG9ydCBhYm91dCBhbiBpbnZhbGlkIHNlc3Npb24gaWQgYW5kIHJlcXVl
c3QgaWQgcmVnZW5lcmF0aW9uICovCisvKiBSQVEgOiBNb25kYXksIDEyIE1hcmNoIDIwMDcgMTE6
NTYgYW0gOiBEZWNsYXJlIHByZXZpb3VzIElELgorICAgUmVtZW1iZXIgdGhlIHByZXZpb3VzbHkg
c2VudCBjb29raWUgdG8gc3VwcHJlc3Mgc2VuZGluZyBvZiB0aGUgc2FtZSBjb29raWUgd2hlbiBv
cGVuaW5nIGFuZAorICAgY2xvc2luZyB0aGUgc2Vzc2lvbiByZXBlYXRlZGx5IHRvIGFsbG93IG90
aGVyIHRocmVhZHMgYWNjZXNzIHRvIHRoZSBzYW1lIHNlc3Npb24gZmlsZS4gKi8KKwljaGFyICpw
cmV2X2lkOwogfSBwaHBfcHNfZ2xvYmFsczsKIAogdHlwZWRlZiBwaHBfcHNfZ2xvYmFscyB6ZW5k
X3BzX2dsb2JhbHM7CkluZGV4OiBzZXNzaW9uLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9z
aXRvcnkvcGhwLXNyYy9leHQvc2Vzc2lvbi9zZXNzaW9uLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9u
IDEuNDY2CmRpZmYgLXUgLXIxLjQ2NiBzZXNzaW9uLmMKLS0tIHNlc3Npb24uYwkyNCBGZWIgMjAw
NyAxNjoyNTo1NSAtMDAwMAkxLjQ2NgorKysgc2Vzc2lvbi5jCTE1IE1hciAyMDA3IDA4OjQ3OjUw
IC0wMDAwCkBAIC0xMTE3LDkgKzExMTcsMjEgQEAKIAogCXNtYXJ0X3N0cl8wKCZuY29va2llKTsK
IAkKKwkvKiBSQVEgOiBNb25kYXksIDEyIE1hcmNoIDIwMDcgMTE6NTYgYW0gOiBQcmV2ZW50IGR1
cGxpY2F0ZSBzZXNzaW9uIGNvb2tpZS4KKwkgICBSZW1lbWJlciB0aGUgcHJldmlvdXNseSBzZW50
IGNvb2tpZSB0byBzdXBwcmVzcyBzZW5kaW5nIG9mIHRoZSBzYW1lIGNvb2tpZSB3aGVuIG9wZW5p
bmcgYW5kCisJICAgY2xvc2luZyB0aGUgc2Vzc2lvbiByZXBlYXRlZGx5IHRvIGFsbG93IG90aGVy
IHRocmVhZHMgYWNjZXNzIHRvIHRoZSBzYW1lIHNlc3Npb24gZmlsZS4gKi8KKwlpZiAoMCAhPSBz
dHJjbXAoUFMoaWQpLCBQUyhwcmV2X2lkKSkpIHsKKwkKIAkvKgkncmVwbGFjZScgbXVzdCBiZSAw
IGhlcmUsIGVsc2UgYSBwcmV2aW91cyBTZXQtQ29va2llCiAJCWhlYWRlciwgcHJvYmFibHkgc2Vu
dCB3aXRoIHNldGNvb2tpZSgpIHdpbGwgYmUgcmVwbGFjZWQhICovCi0Jc2FwaV9hZGRfaGVhZGVy
X2V4KG5jb29raWUuYywgbmNvb2tpZS5sZW4sIDAsIDAgVFNSTUxTX0NDKTsKKwkJc2FwaV9hZGRf
aGVhZGVyX2V4KG5jb29raWUuYywgbmNvb2tpZS5sZW4sIDAsIDAgVFNSTUxTX0NDKTsKKworCS8q
IFJBUSA6IE1vbmRheSwgMTIgTWFyY2ggMjAwNyAxMTo1NiBhbSA6IFJlbWVtYmVyIGlkLgorCSAg
IFJlbWVtYmVyIHRoZSBwcmV2aW91c2x5IHNlbnQgY29va2llIHRvIHN1cHByZXNzIHNlbmRpbmcg
b2YgdGhlIHNhbWUgY29va2llIHdoZW4gb3BlbmluZyBhbmQKKwkgICBjbG9zaW5nIHRoZSBzZXNz
aW9uIHJlcGVhdGVkbHkgdG8gYWxsb3cgb3RoZXIgdGhyZWFkcyBhY2Nlc3MgdG8gdGhlIHNhbWUg
c2Vzc2lvbiBmaWxlLiAqLworCQlzdHJjcHkoUFMocHJldl9pZCksIFBTKGlkKSwgc3RybGVuKFBT
KGlkKSkpOworCisJfQogfQogCiBQSFBBUEkgcHNfbW9kdWxlICpfcGhwX2ZpbmRfcHNfbW9kdWxl
KGNoYXIgKm5hbWUgVFNSTUxTX0RDKQpAQCAtMTgyOSw2ICsxODQxLDEwIEBACiAJcHNfZ2xvYmFs
cy0+bW9kX2RhdGEgPSBOVUxMOwogCXBzX2dsb2JhbHMtPnNlc3Npb25fc3RhdHVzID0gcGhwX3Nl
c3Npb25fbm9uZTsKIAlwc19nbG9iYWxzLT5odHRwX3Nlc3Npb25fdmFycyA9IE5VTEw7CisvKiBS
QVEgOiBNb25kYXksIDEyIE1hcmNoIDIwMDcgMTE6NTYgYW0gOiBJbml0aWFsaXplIHByZXZpb3Vz
IGlkLgorICAgUmVtZW1iZXIgdGhlIHByZXZpb3VzbHkgc2VudCBjb29raWUgdG8gc3VwcHJlc3Mg
c2VuZGluZyBvZiB0aGUgc2FtZSBjb29raWUgd2hlbiBvcGVuaW5nIGFuZAorICAgY2xvc2luZyB0
aGUgc2Vzc2lvbiByZXBlYXRlZGx5IHRvIGFsbG93IG90aGVyIHRocmVhZHMgYWNjZXNzIHRvIHRo
ZSBzYW1lIHNlc3Npb24gZmlsZS4gKi8KKwlwc19nbG9iYWxzLT5wcmV2X2lkID0gTlVMTDsKIH0K
IAogc3RhdGljIFBIUF9NSU5JVF9GVU5DVElPTihzZXNzaW9uKQo=
------=_Part_54674_3193325.1173950146249--