# A request for code change : Repeated opening and closing the session leads to a LOT of Set-Cookie headers.

- Thread: https://externals.io/message/28337
- Original archive: https://news-web.php.net/php.internals/28337
- Started by Richard Quadling on 2007-03-14T11:37:46+00:00
- Messages: 10
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #28337 — Richard Quadling — 2007-03-14T11:37:46+00:00

URL: https://externals.io/message/28337#28337

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!"

---

## #28339 — Markus Fischer — 2007-03-14T19:05:41+00:00

URL: https://externals.io/message/28337#28339 · In reply to: #28337

-----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

---

## #28342 — Richard Quadling — 2007-03-15T09:15:46+00:00

URL: https://externals.io/message/28337#28342 · In reply to: #28339

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.




> -----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:
> > […]
>
> -----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!"

---

## #28343 — Markus Fischer — 2007-03-15T11:36:05+00:00

URL: https://externals.io/message/28337#28343 · In reply to: #28342

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Richard,

Richard Quadling wrote:
> 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.

Yes, that's true.

> 2 - For the main process to update the session, a `session_start()` is
> required which generates the Set-Cookie header.

Maybe I misunderstand your code examples, but I thought that the long
running process is the on with the UpdateSession() calls. So
successively calling UpdateSession() generated successive Cookie headers
sent to the browser in turn creating the IE specific problems.

So, my suggestion was: you don't need to call `session_start()` inside
UpdateSession(), because upon the first `session_start()` you know the
session ID and therefore can update the database inside UpdateSession()
without having to use the PHP functions, thus avoiding the particular
problematic areas in the C code.

However, this does not judge in anyway your proposal for the patch.

- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+S+l1nS0RcInK9ARAuKyAKCYsIWc98KLgOgq+MVGBCafL8l98wCg4Qz7
NXS95MxlJkL8h3EiGF4XTac=
=43oX
-----END PGP SIGNATURE

---

## #28344 — Stefan Esser — 2007-03-15T12:12:15+00:00

URL: https://externals.io/message/28337#28344 · In reply to: #28337

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.
>
> > […]
> 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.

---

## #28345 — Richard Quadling — 2007-03-15T12:22:24+00:00

URL: https://externals.io/message/28337#28345 · In reply to: #28344

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);
?>


> 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:
> > […]
>
>


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

---

## #28346 — Richard Quadling — 2007-03-15T12:46:40+00:00

URL: https://externals.io/message/28337#28346 · In reply to: #28345

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.




> 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);
> ?>
>
> 
> > […]
>
>
> --
> -----
> 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!"

---

## #28361 — Richard Lynch — 2007-03-15T19:21:15+00:00

URL: https://externals.io/message/28337#28361 · In reply to: #28342

> 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.

You could, in theory, write your own "SetSessionData" function which
stored into $_SESSION and *also* updated something somewhere
immediately, for the external process to read...

It would probably suck for large amounts of session data, but could
work nicely and solve your problem otherwise.

I'm not saying PHP shouldn't be smart enough to only send the one
header, as it is already caching other headers and only sending one
unless you add that second arg to `header()` anyway, so all the hooks
are there -- Just that you could fix it today instead of waiting on a
change to PHP source to happen.

> 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.

Do whatever is done by the Userland `header()` function, which buffers
headers and only sends one.

That's been working for ages. :-)

> 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.

I think you still need locking in PHP Userland for concurrent access
to be meaningful to most developers...

Otherwise you end up with a race condition in the session save handler.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

---

## #28364 — David Lindstrom — 2007-03-16T01:20:14+00:00

URL: https://externals.io/message/28337#28364 · In reply to: #28346

Well, you could always add a user comment. Isn't that what they are for 
anyway?


""Richard Quadling"" <rquadling@googlemail.com> 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.
>
>
>
> 
> > […]
>
>
> -- 
> -----
> Richard Quadling
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> "Standing on the shoulders of some very clever giants!"

---

## #28368 — Richard Quadling — 2007-03-16T10:28:26+00:00

URL: https://externals.io/message/28337#28368 · In reply to: #28361

> I think you still need locking in PHP Userland for concurrent access
> to be meaningful to most developers...
>
> Otherwise you end up with a race condition in the session save handler.

As only 1 process can hold the session at a time and the main process
is constantly "letting go" by `session_write_close()`, other processes
are able to open/read/close (to get the current status) or
open/write/close (to tell the main process to abort).

Without the `session_write_close()` in the main process, the secondary
processes will wait either for the appropriate `set_time_limit()` or
until the main process script ends. Which is correct.

This is working very well for me now.

It was the extra Set-Cookie headers which screwed things up for IE. By
using ini_set('sessions.use_cookies', 0); immediately after the
 `session_start()` in the main process, the problem has been solved. The
main process doesn't output any urls/forms/etc, so the session id is
not appended to any urls.

If the session cookie could be cached then that would be great, but I
need someone else to look at the supplied patch (I'm not that good
with PHP internals).

Richard.

-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"