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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
