cgi-session-user — CGI::Session users mailing list

[Cgi-session-user] Re: [cpan #14414] method remote_addr() was removed in version 4.01

[Mark S. <ma...@su...>]

On Fri, Sep 02, 2005 at 05:17:16AM -0400, Guest via RT wrote:
> 
> This message about CGI-Session was sent to you by guest <> via rt.cpan.org
> 
> Full context and any attached attachments can be found at:
> <URL: https://rt.cpan.org/Ticket/Display.html?id=14414 >
> 
> I've upgraded today from 3.95 to the latest 4.01 and I've experienced
> that the method remote_addr() is still documented but inimplemented.

Thanks for the report. I've upgraded this to 'Critical'. 

A patch is welcome (should be easy), or someone else get to this soon.

We'll also want an automated test to that checks for this as well.

    Mark

[Cgi-session-user] CGI::Session 4.0 released

[Sherzod R. <she...@ha...>]

What's new in CGI::Session 4.00?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

	* NEW: load() constructor method loads sessions, but doesn't create
	  new session if requested session cannot be loaded.
	* NEW: is_expired() intercepts expired sessions.
	* NEW: is_empty() intercepts requests for inexistent sessions.
	* NEW: find() to traverse session data on disk.
	* NEW: SQLite driver
	* NEW: PostgreSQL driver enhanced to work better with binary
serializers (Matt LeBlanc)
	* NEW: updated and improved driver specifications
	* NEW: standard testing framework.
	* FIX: Providing an expire time like "-10" now works (Mark Stosberg)
	* FIX: Support for CGI::Simple is confirmed, resolving RT#6141 (Mark
Stosberg)
	* FIX: update to untainting in default serializer to make "-T" happy
(Matt LeBlanc)
	* DOCS: More complete driver specs documented

For an extended list see Changes file in the distribution.

Thanks to Mark Stosberg, Matt LeBlanc, Shawn Sorichetti and Jason Crome =
for
making this distribution possible.


DOWNLOAD
=3D=3D=3D=3D=3D=3D=3D=3D=3D

CGI::Session should be available from your nearest CPAN mirror shortly. =
Look
for the distribution named CGI-Session-4.00.tar.gz

-- =20
Sherzod Ruzmetov

RE: [Cgi-session-user] All tests passing.

[Sherzod R. <she...@ha...>]

Mark,

> Unless there are any other concerns, do you want to do the honors
> Sherzod?

With pleasure!

CGI::Session 4.0 coming up!

[Cgi-session-user] All tests passing.

[Mark S. <ma...@su...>]

Hello,

I'm happy to report that with the recent fixes from Matt LeBlanc and
Sherzod, all tests are now passing for me with the latest CGI::Session
from Subversion. 

I've reviewed the TODO file and think we are ready for a 4.0 release. 

I added a disclaimer to the 'Changes' file that people should exercise
upgrading at this point. 

Unless there are any other concerns, do you want to do the honors
Sherzod?

    Mark

-- 
http://mark.stosberg.com/ 

[Cgi-session-user] t/g4_sqlite_storable.t fixed

[Sherzod R. <she...@ha...>]

SQLite supports blob columns. Why t/g4_sqlite_storable.t tests have been
failing is still a mystery to me. Until we figure it out, I've forced =
sqlite
to get along with Storable by encoding Storable's output using base64
encoding.

Unfortunately, this means, to be able to use sqlite driver MIME::Base64 =
has
to be installed. I expect MIME::Base64 to be available in most =
computers,
since it's a widely used library.

Checkout updated Session/Driver/sqlite.pm.

Re: [Cgi-session-user] problem with my session management

[Mark S. <ma...@su...>]

On Thu, Aug 25, 2005 at 03:31:49AM -0700, sanjay raju wrote:
> hellow sir,
>  
> I have a problem with my session mamagement in login
> form.
> 
> problem comes when i logoff my session and click back
> button on toolbar of the browser ,it shows my previous
> page which should not happen.

If I understand your problem, there is not a C::S problem, when you
click "back" in a browser, you are probably looking at a cached page,
which your web server has little control over. 

If that's the case, you should look into what headers to set to minimize
this, and general browser caching issues.

If you suspect there is a bug in CGI::Session, please let us know
what version you are using, and reduce it to a test script that you can
submit to the list for review.

    Mark

[Cgi-session-user] problem with my session management

[sanjay r. <san...@ya...>]

hellow sir,
 
I have a problem with my session mamagement in login
form.

problem comes when i logoff my session and click back
button on toolbar of the browser ,it shows my previous
page which should not happen.

let me be more clear .

my session should be able to go back and farword by
using  
back and farword button on toolbar when the user is
still
login , but onece he logoff , there should be no
access to the pages unless he loggin again . 

please help me to solve this problem .

thank u

sanjay pinnamaraju

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Cgi-session-user] update: PostgreSQL driver improved

[Mark S. <ma...@su...>]

Thanks to Matt LeBlanc, the PostgreSQL driver is now improved
and works better with binary driver types.

Does someone want to tackle make the SQLite/Storable tests TODO ? 

 t/g4_sqlite_storable.t

I know it's not hard, I'm just about out of steam tonight, but I want the progress
to continue. We are about ready to release, I think!

    Mark

-- 
http://mark.stosberg.com/ 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #76 - 1 msg

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #75 - 1 msg

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #74 - 3 msgs

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

Re: [Cgi-session-user] Re: question regarding CGI::Session

[Mark S. <ma...@su...>]

> We should probably start thinking of production release of CGI::Session 4.x 
> already. What do you think Mark?

I think we are about ready. I have some patches which I just got today
for PostgreSQL/Storable bug fixes.

I am also in the processing of using TODO or SKIP to address the failing
SQLite/Storable failures, and documenting that they don't work together.

Finally, there are some other Storable failures which I wrote about
recently which need to be addressed somehow before release. I'm most
concerned about those, because they appear to be regressions.

Otherwise, I think we are ready, although I think we might ad disclaimer
in the changelog that much as changed and people are encouraged to do
their own compatibility testing before using it production (Although as
far as we know, it /should/ be a smooth upgrade).

    Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[Cgi-session-user] Re: question regarding CGI::Session

[Sherzod R. <she...@na...>]

> Here is what I am planning to do. Please let me know,
> if I am correct.
>
> In my script 1, I will do
> my $session = new CGI::Session("driver:File", undef,
> {Directory=>'/u/uname/www/temp/'});
> my $CGISESSID = $session->id();
> $session->param(-name=>'l_name', -value=>$CGISESSID);
> $session->expire('+5m');
>
> what this does basically is, it creates a file in temp
> directory
>> cat cgisess_1ea55e0535761d4361c1c3abcf3fe092
> $D = {"l_name" =>
> "1ea55e0535761d4361c1c3abcf3fe092","_SESSION_EXPIRE_LIST"
> => {},"_SESSION_REMOTE_ADDR" =>
> "172.19.31.217","_SESSION_ATIME" =>
> "1124205645","_SESSION_CTIME" =>
> "1124205645","_SESSION_ID" =>
> "1ea55e0535761d4361c1c3abcf3fe092","_SESSION_ETIME" =>
> 300};
>
> Now from script 1 i go to  script 2 and pass the
> parameter, sid=1ea55e0535761d4361c1c3abcf3fe092
> through thte url
>
> In script 2, i will grab the parameter, $sid =
> param('sid')
> then i will open the file  cgisess_$sid and grab the
> paramter "_SESSION_ID" if this value matches with
> $sid, means the session is valid, otherwise invalid.
>
> Does this makes sense?

I'm afraid to accept it, but it kinda makes sense to me, although it shouldn't. That's where  you're going astray though:

 	FIRST: You shouldn't know anything about how session data is being stored. Nor should you care. It's the job of
CGI::Session to handle those details for you. All you have to do is follow CGI::Session's documented interface, which you
can find at http://search.cpan.org/perldoc?CGI::Session

 	SECOND: When you decide to pass session information in the QUERY_STRING, by default you have to use 'CGISESSID' as the
parameter, because that's where CGI::Session will look for a claimed id. If you have to use some other name for your session parameter,
you have to tell CGI::Session about it before  you call new():

 	CGI::Session->name("sid");	# <-- now you can pass ?sid=1341241412413241241234 in the URL
 	$s = CGI::Session->new("driver:File", undef, undef);

 	THIRD: Only CGI::Session decides whether claimed session id is valid, so you should never have to try to validate session id on your own. In fact, you shouldn't even care! If the claimed ID is not valid, CGI::Session is not going to use it. It will just create a new, empty session. If the client is requesting a session that was expired, it will remove the session and will create a new session, again.

>
> The only problem how can i delete that session, if i
> don't delete, the file
> cgisess_1ea55e0535761d4361c1c3abcf3fe092, it will
> remain on the server forever. I can delete if someone
> hits logout button,but what if someone does not hit
> logout button and close the browser.

Until CGI::Session 4.x it is something we all had to live with. The ones who didn't,however, did this:

 	find /tmp -name "cgisess_*" -atime 7 | xargs rm -f

which worked with verying levels of success. Sarting in CGI::Session 4.x, there is a new experimental feature, find(), 
which can replace the above command, and works for almost all the drivers (including sqlite, csv, mysql etc).

We should probably start thinking of production release of CGI::Session 4.x already. What do you think Mark?

-- 
Sherzod Ruzmetov

[Cgi-session-user] Re: CGI::Session::Driver::postgresql

[Mark S. <ma...@su...>]

Thanks Matt.

To confirm: 

The BYTEA updates are needed because binary characters are involved,
but could be avoided otherwise.

Is there any penalty for using BYTEA when the data is plain text? 

I'm wondering if we should still make plain-text backends an option, for
people who use a serializer that works with plain text.

Also, I believe the PostgreSQL driver for 3.x used the 'text' type. It
would be very nice if those folks could upgrade directly to 4.x without
changing the data type of one of their database columns.

Is there any reason to just recommend people use the plain-text Dumper
format with PostgreSQL  to keey things simple? 

    Mark

On Wed, Aug 17, 2005 at 04:10:40PM -0500, Matt LeBlanc wrote:
> Sorry it took so long to provide you with this patch. It's a quick hack 
> so feel free to update it as you see fit.
> 
> As a reminder, this patch fixes problems one might experience when (s)he 
> uses Storable or FreezeThaw as the serializer.
> 
> Thanks,
> Matt LeBlanc

> --- postgresql-old.pm	Wed Aug 17 15:51:37 2005
> +++ postgresql.pm	Wed Aug 17 16:03:54 2005
> @@ -15,13 +15,48 @@
>  
>  
>  use strict;
> +use Carp "croak";
>  #use diagnostics;
>  
>  use CGI::Session::Driver::DBI;
> +use DBD::Pg "PG_BYTEA";
>  
>  $CGI::Session::Driver::postgresql::VERSION = '2.01';
>  @CGI::Session::Driver::postgresql::ISA     = qw( CGI::Session::Driver::DBI );
>  
> +sub store {
> +    my $self = shift;
> +    my ($sid, $datastr) = @_;
> +    croak "store(): usage error" unless $sid && $datastr;
> +
> +    my $dbh = $self->{Handle};
> +    my $sth = $dbh->prepare("SELECT id FROM " . $self->table_name . " WHERE id=?");
> +    unless ( defined $sth ) {
> +        return $self->set_error( "store(): \$sth->prepare failed with message " . $dbh->errstr );
> +    }
> +
> +    $sth->execute( $sid ) or return $self->set_error( "store(): \$sth->execute failed with message " . $dbh->errstr );
> +    if ( $sth->fetchrow_array ) {
> +        __ex_and_ret($dbh,"UPDATE " . $self->table_name . " SET a_session=? WHERE id=?",$datastr,$sid) 
> +            or return $self->set_error( "store(): \$dbh->do failed " . $dbh->errstr );
> +    } else {
> +        __ex_and_ret($dbh,"INSERT INTO " . $self->table_name . " (a_session,id) VALUES(?, ?)",$datastr, $sid) 
> +            or return $self->set_error( "store(): \$dbh->do failed " . $dbh->errstr );
> +    }
> +    return 1;
> +}
> +
> +sub __ex_and_ret {
> +    my ($dbh,$sql,$datastr,$sid) = @_;
> +    eval {
> +        local @SIG{qw(__DIE__ __WARN__)};
> +        my $sth = $dbh->prepare($sql) or return 0;
> +        $sth->bind_param(1,undef,{pg_type => PG_BYTEA}) or return 0;
> +        $sth->execute($datastr,$sid) or return 0;
> +    };
> +    return 0 if $@;
> +    return 1;
> +}
>  
>  1;
>  
> @@ -38,7 +73,18 @@
>  
>  =head1 DESCRIPTION
>  
> -CGI::Session::PostgreSQL is a CGI::Session driver to store session data in a PostgreSQL table. More details see L<CGI::Session::Driver::DBI|CGI::Session::Driver::DBI>, its parent class.
> +CGI::Session::PostgreSQL is a CGI::Session driver to store session data in a PostgreSQL table.
> +
> +=head1 STORAGE
> +
> +Before you can use any DBI-based session drivers you need to make sure compatible database table is created for CGI::Session to work with. Following command will produce minimal requirements in most SQL databases:
> +
> +    CREATE TABLE sessions (
> +        id CHAR(32) NOT NULL PRIMARY KEY,
> +        a_session BYTEA NOT NULL
> +    );
> +
> +For more details see L<CGI::Session::Driver::DBI|CGI::Session::Driver::DBI>, its parent class.
>  
>  =head1 COPYRIGHT
>  

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #72 - 1 msg

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #71 - 2 msgs

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

Re: [Cgi-session-user] re: calling flush automatically

[David S. <dav...@we...>]

Thanks Mark,

I'll give that a try.. The examples I've read included the braces.

Regards,

David

----- Original Message ----- 
From: "Mark Stosberg" <ma...@su...>
To: "Session mailing list" <Cgi...@li...>
Sent: Friday, August 12, 2005 11:58 PM
Subject: [Cgi-session-user] re: calling flush automatically


I looked more into the issue of why flush wasn't being called
automatically by the recent poster, and also compared the behavior of
3.x and 4.x and this regard. Here's the test script I played with:

####
  use File::Spec;
  use Test::More qw/no_plan/;
  use strict;

  use CGI::Session;
  my $dir = File::Spec->catdir('t', 'sessiondata');
  my $id;
  {
      my $ses = CGI::Session->new(undef,undef,{Directory=> $dir });
      $id = $ses->id();
      ok($id, "found session id");
  }

  ok(-r "$dir/cgisess_".$id, "found session data file");
####

With both 3.x and 4.x, both the tests will pass, meaning the session is 
being
flushed automatically.

Remove the brackets to provide the scope, and the second text fails (for
both versions).

    Mark



-- 
http://mark.stosberg.com/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Cgi-session-user mailing list
Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #70 - 1 msg

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #69 - 3 msgs

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Help requested for release: Storable issues

[Mark S. <ma...@su...>]

Hello, 

I was just reviewing the cpan-testers report for CGI::Session, and they are
mostly test failures. This is sad, considering they are skipping the MySQL and
PostgreSQL tests in all cases, I think. 

The things that have been reported not to work include: 

- db_file    with Storable
- SQLite     with Storable 
- PostgreSQL with Storable

I'm fine with just TODO'ing the SQLite and PostgreSQL failures with Storable, since I don't think
those were tested to work with 3.x, and I don't personally care about them-- there are other good
seriarlizers to use. 

The db_file/Storable failure is more troubling, because we had a test
for that in 3.95, and cpan-testers reports no failures for it out of 58
tests. 

Could someone look into these Storable issues so we can get 4.0 released? I don't personally care
about that serializer, so am unlikely to get to it myself.

I believe part of the issue is that Storable is using a binary data
format. 

With SQLite, this means encoding and decoding needs to be done.
DBD::SQLite2 makes reference to such a feature, but at the expense of
possibly breaking other things. I would just assume document not to use
these two together. 

Likewise, I think PostgreSQL objects to storing binary data in a text
field. While a different data type could be used along with functions to
handle binaries, again I would rather say: "Don't do that", at least for now. 

Why db_file/storable is failing, I have no idea. 

    Mark


t/api3_db_file_storable.........Use of uninitialized value in subroutine entry at /opt/perl/testers/.cpanplus/5.8.7/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Driver/db_file.pm line 57.
Can't use string ("") as a subroutine ref while "strict refs" in use at /opt/perl/testers/.cpanplus/5.8.7/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Driver/db_file.pm line 57.
Use of uninitialized value in subroutine entry at /opt/perl/testers/.cpanplus/5.8.7/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Driver/db_file.pm line 57.
        (in cleanup) Can't use string ("") as a subroutine ref while "strict refs" in use at /opt/perl/testers/.cpanplus/5.8.7/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Driver/db_file.pm line 57.
# Looks like you planned 14 tests but only ran 9.





t/g4_sqlite.....................DBD::SQLite::db selectrow_array failed: no such table: sessions(1) at dbdimp.c line 268 at t/g4_sqlite.t line 26.
Use of uninitialized value in concatenation (.) or string at /net/sunu991/disc1/.cpanplus/5.8.5/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Test/Default.pm line 162.
ok
        6/79 skipped: Default serializer cannot serialize objects properly
t/g4_sqlite_freezethaw..........Use of uninitialized value in concatenation (.) or string at /net/sunu991/disc1/.cpanplus/5.8.5/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Test/Default.pm line 162.
ok
t/g4_sqlite_storable............
#     Failed test (/net/sunu991/disc1/.cpanplus/5.8.5/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Test/Default.pm at line 128)
#          got: 'load(): couldn't thaw() data using CGI::Session::Serialize::storable :'
#     expected: ''

#     Failed test (/net/sunu991/disc1/.cpanplus/5.8.5/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Test/Default.pm at line 129)
Can't call method "is_expired" on an undefined value at /net/sunu991/disc1/.cpanplus/5.8.5/build/CGI-Session-4.00_09/blib/lib/CGI/Session/Test/Default.pm line 130.
# Looks like you planned 79 tests but only ran 24.
# Looks like your test died just after 24.
dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 23-79

-- 
http://mark.stosberg.com/ 

[Cgi-session-user] re: calling flush automatically

[Mark S. <ma...@su...>]

I looked more into the issue of why flush wasn't being called
automatically by the recent poster, and also compared the behavior of
3.x and 4.x and this regard. Here's the test script I played with:

####
  use File::Spec;
  use Test::More qw/no_plan/;
  use strict;
  
  use CGI::Session;
  my $dir = File::Spec->catdir('t', 'sessiondata');
  my $id;
  {
      my $ses = CGI::Session->new(undef,undef,{Directory=> $dir });
      $id = $ses->id();
      ok($id, "found session id");
  }
  
  ok(-r "$dir/cgisess_".$id, "found session data file");
####

With both 3.x and 4.x, both the tests will pass, meaning the session is being
flushed automatically. 

Remove the brackets to provide the scope, and the second text fails (for
both versions). 

    Mark



-- 
http://mark.stosberg.com/ 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #68 - 1 msg

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

[Cgi-session-user] Re: Cgi-session-user digest, Vol 1 #67 - 3 msgs

[Ronald K. <ro...@um...>]

The BioMediaLab is closed Aug 12 - 22. We will respond to your email when we reopen. Thanks 

Re: [Cgi-session-user] Problem setting up CGI::Session

[David S. <dav...@we...>]

I didn't mean to start something big here :)

----- Original Message ----- 
From: "Mark Stosberg" <ma...@su...>
To: <cgi...@li...>
Sent: Thursday, August 11, 2005 9:52 AM
Subject: Re: [Cgi-session-user] Problem setting up CGI::Session


On Thu, Aug 11, 2005 at 03:42:07AM -0400, Sherzod Ruzmetov wrote:
> > Is that something that should always be done after doing
> > any updates to the
> > > session?
> >
> > It shouldn't be needed, as long as the session object goes out of
> > scope by the end of your request.  The session is not written to disk
> > until the DESTROY method of the CGI::Session object is called (which
> > happens automatically when the object is garbage collected).
>
> True, theoretically, flush() should never be called by a program.
> CGI::Session should call it automatically at the end of the session.
> Howerver, in some rare instances, I noticed this doesn't happen, and 
> calling
> flush() manually is the only fix.
>
> I know it's not very comforting for you guys to hear me say this, but I'm
> not sure what the problem is either. It sounds like something to do with 
> the
> way session's state data (_STATUS attribute) is kept track, and it may be
> buggy.

Could someone try the same test using 3.95 and if see if the result is
the same?

That for me would determine if we need to address this for the 4.0
release, which I would otherwise feel good about releasing into the world
Real Soon Now.

    Mark



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Cgi-session-user mailing list
Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] Problem setting up CGI::Session

[Mark S. <ma...@su...>]

On Thu, Aug 11, 2005 at 03:42:07AM -0400, Sherzod Ruzmetov wrote:
> > Is that something that should always be done after doing 
> > any updates to the
> > > session?
> > 
> > It shouldn't be needed, as long as the session object goes out of
> > scope by the end of your request.  The session is not written to disk
> > until the DESTROY method of the CGI::Session object is called (which
> > happens automatically when the object is garbage collected).
> 
> True, theoretically, flush() should never be called by a program.
> CGI::Session should call it automatically at the end of the session.
> Howerver, in some rare instances, I noticed this doesn't happen, and calling
> flush() manually is the only fix.
> 
> I know it's not very comforting for you guys to hear me say this, but I'm
> not sure what the problem is either. It sounds like something to do with the
> way session's state data (_STATUS attribute) is kept track, and it may be
> buggy.

Could someone try the same test using 3.95 and if see if the result is
the same? 

That for me would determine if we need to address this for the 4.0
release, which I would otherwise feel good about releasing into the world
Real Soon Now. 

    Mark