You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Aaron Johnson <so...@gina.net> on 2003/02/23 00:31:49 UTC
Re: Session and redirect oddity
As a follow up to this issue I wanted to post what I believe caused this
issue. The problem has to do with the size of the available session
storage method. The volume of information being stored in the session
data was exceeding the available column size in the MySQL database
table. Once I increased the column size the problems went away. A
failed called to the session backend was resulting in a null udat value.
I realize that storing more then 64K worth of data (the default size of
the session content field) is not a common problem or the prescribed way
to use sessions, however I am not sure where a condition that exceeds it
should/is caught. Should Apache::Session(X) or Embperl produce an
appropriate message in the logs for this?
Aaron Johnson
On Wed, 2003-01-08 at 01:00, Aaron Johnson wrote:
> On Mon, 2002-12-23 at 00:39, Gerald Richter wrote:
> > > On Sun, 2002-12-22 at 17:24, Gerald Richter wrote:
> > > > > [13048]SES: Send Cookie ->
> > > > > EMBPERL_UID=5a90da88079e1848df918cecd95d06a2; path=/; expires=+30m
> > > >
> >
> > Could you try without the EXPIRES setting? Embperl 2.0 for now only accepts
> > absolut times. It doesn't convert relativ times to absolute ones and +30m is
> > not valid to send in a cookie. Maybe this is the problem....
> >
>
> Sorry for the slow reply, just back from my vacation. I removed the
> expires, but the behavior remains the same.
>
> > > > ok, so Embperl tries to send the cookie. Please tell your browser to ask
> > > > whenever to accept a cookie. That should show you if the cookie is
> > really
> > > > send to your browser or not
> > > >
> > >
> > > The cookie is being sent on the first page requested corrected. However
> > > after I login the page that seems to send the second cookie doesn't ask
> > > to send the cookie and the old cookie data is lost.
> > >
> >
> > Embperl always sends the cookie only once, but the browser should send it
> > back everytime.
> >
> > To force Embperl to resend the cookie, you can call
> > [-
> > $r = shift ;
> > $r -> RefreshSession ;
> > -]
> >
>
> I added this and it seems to have helped. I added it on the initial
> page the user is taken to as well as the login page. I hope to have
> time to test more throughly this week.
>
> Thanks.
>
> Aaron
>
> > Gerald
> >
> >
> > -------------------------------------------------------------
> > Gerald Richter ecos electronic communication services gmbh
> > Internetconnect * Webserver/-design/-datenbanken * Consulting
> >
> > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> > E-Mail: richter@ecos.de Voice: +49 6133 925131
> > WWW: http://www.ecos.de Fax: +49 6133 925152
> > -------------------------------------------------------------
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session and redirect oddity
Posted by Gerald Richter <ri...@ecos.de>.
> I did some investigating and found that the MySQL behavior for this type
> of problem is to simply report a warning and cut off the text being
> entered if it exceeds the field length. The session data is becoming
> invalid because in this case the Perl data structure is being
> corrupted. The section of code related to this problem is in the
> Apache::Session::Store::DBI module. While RaiseError is turned on,
> MySQL doesn't return a "hard" error that the length of data exceeds the
> field size.
>
There are two DBI attributes which you can pass to the connect call, called
LongTruncOk and LongReadLen, with which you can set the behaviour in case of
a truncation. At the moment there is no chance to pass these attributes. So
you have to patch Apache::Session::Store::MySQL.
Gerald
--------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
--------------------------------------------------------------
|
| Besuchen Sie uns auf der CeBIT vom 12. - 19. März 2003
| Messe Hannover * Halle 17 * Stand F 36
| http://www.cebit.de/
|
+-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session and redirect oddity
Posted by Aaron Johnson <so...@gina.net>.
I did some investigating and found that the MySQL behavior for this type
of problem is to simply report a warning and cut off the text being
entered if it exceeds the field length. The session data is becoming
invalid because in this case the Perl data structure is being
corrupted. The section of code related to this problem is in the
Apache::Session::Store::DBI module. While RaiseError is turned on,
MySQL doesn't return a "hard" error that the length of data exceeds the
field size.
Aaron
On Mon, 2003-02-24 at 02:41, Gerald Richter wrote:
> > As a follow up to this issue I wanted to post what I believe caused this
> > issue. The problem has to do with the size of the available session
> > storage method. The volume of information being stored in the session
> > data was exceeding the available column size in the MySQL database
> > table. Once I increased the column size the problems went away. A
> > failed called to the session backend was resulting in a null udat value.
> >
> > I realize that storing more then 64K worth of data (the default size of
> > the session content field) is not a common problem or the prescribed way
> > to use sessions, however I am not sure where a condition that exceeds it
> > should/is caught. Should Apache::Session(X) or Embperl produce an
> > appropriate message in the logs for this?
> >
>
> Thanks for the feedback.
>
> I think Apache::Session::Store::Mysql would be the right place to check
> this, since this constrain does not exists for other storage.
>
> We could also overload this store and place a subclass in the
> Apache::SessonX package.
>
> Gerald
>
>
> > Aaron Johnson
> >
> > On Wed, 2003-01-08 at 01:00, Aaron Johnson wrote:
> > > On Mon, 2002-12-23 at 00:39, Gerald Richter wrote:
> > > > > On Sun, 2002-12-22 at 17:24, Gerald Richter wrote:
> > > > > > > [13048]SES: Send Cookie ->
> > > > > > > EMBPERL_UID=5a90da88079e1848df918cecd95d06a2; path=/;
> expires=+30m
> > > > > >
> > > >
> > > > Could you try without the EXPIRES setting? Embperl 2.0 for now only
> accepts
> > > > absolut times. It doesn't convert relativ times to absolute ones and
> +30m is
> > > > not valid to send in a cookie. Maybe this is the problem....
> > > >
> > >
> > > Sorry for the slow reply, just back from my vacation. I removed the
> > > expires, but the behavior remains the same.
> > >
> > > > > > ok, so Embperl tries to send the cookie. Please tell your browser
> to ask
> > > > > > whenever to accept a cookie. That should show you if the cookie is
> > > > really
> > > > > > send to your browser or not
> > > > > >
> > > > >
> > > > > The cookie is being sent on the first page requested corrected.
> However
> > > > > after I login the page that seems to send the second cookie doesn't
> ask
> > > > > to send the cookie and the old cookie data is lost.
> > > > >
> > > >
> > > > Embperl always sends the cookie only once, but the browser should send
> it
> > > > back everytime.
> > > >
> > > > To force Embperl to resend the cookie, you can call
> > > > [-
> > > > $r = shift ;
> > > > $r -> RefreshSession ;
> > > > -]
> > > >
> > >
> > > I added this and it seems to have helped. I added it on the initial
> > > page the user is taken to as well as the login page. I hope to have
> > > time to test more throughly this week.
> > >
> > > Thanks.
> > >
> > > Aaron
> > >
> > > > Gerald
> > > >
> > > >
> > > > -------------------------------------------------------------
> > > > Gerald Richter ecos electronic communication services gmbh
> > > > Internetconnect * Webserver/-design/-datenbanken * Consulting
> > > >
> > > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> > > > E-Mail: richter@ecos.de Voice: +49 6133 925131
> > > > WWW: http://www.ecos.de Fax: +49 6133 925152
> > > > -------------------------------------------------------------
> > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > > For additional commands, e-mail: embperl-help@perl.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session and redirect oddity
Posted by Gerald Richter <ri...@ecos.de>.
> As a follow up to this issue I wanted to post what I believe caused this
> issue. The problem has to do with the size of the available session
> storage method. The volume of information being stored in the session
> data was exceeding the available column size in the MySQL database
> table. Once I increased the column size the problems went away. A
> failed called to the session backend was resulting in a null udat value.
>
> I realize that storing more then 64K worth of data (the default size of
> the session content field) is not a common problem or the prescribed way
> to use sessions, however I am not sure where a condition that exceeds it
> should/is caught. Should Apache::Session(X) or Embperl produce an
> appropriate message in the logs for this?
>
Thanks for the feedback.
I think Apache::Session::Store::Mysql would be the right place to check
this, since this constrain does not exists for other storage.
We could also overload this store and place a subclass in the
Apache::SessonX package.
Gerald
> Aaron Johnson
>
> On Wed, 2003-01-08 at 01:00, Aaron Johnson wrote:
> > On Mon, 2002-12-23 at 00:39, Gerald Richter wrote:
> > > > On Sun, 2002-12-22 at 17:24, Gerald Richter wrote:
> > > > > > [13048]SES: Send Cookie ->
> > > > > > EMBPERL_UID=5a90da88079e1848df918cecd95d06a2; path=/;
expires=+30m
> > > > >
> > >
> > > Could you try without the EXPIRES setting? Embperl 2.0 for now only
accepts
> > > absolut times. It doesn't convert relativ times to absolute ones and
+30m is
> > > not valid to send in a cookie. Maybe this is the problem....
> > >
> >
> > Sorry for the slow reply, just back from my vacation. I removed the
> > expires, but the behavior remains the same.
> >
> > > > > ok, so Embperl tries to send the cookie. Please tell your browser
to ask
> > > > > whenever to accept a cookie. That should show you if the cookie is
> > > really
> > > > > send to your browser or not
> > > > >
> > > >
> > > > The cookie is being sent on the first page requested corrected.
However
> > > > after I login the page that seems to send the second cookie doesn't
ask
> > > > to send the cookie and the old cookie data is lost.
> > > >
> > >
> > > Embperl always sends the cookie only once, but the browser should send
it
> > > back everytime.
> > >
> > > To force Embperl to resend the cookie, you can call
> > > [-
> > > $r = shift ;
> > > $r -> RefreshSession ;
> > > -]
> > >
> >
> > I added this and it seems to have helped. I added it on the initial
> > page the user is taken to as well as the login page. I hope to have
> > time to test more throughly this week.
> >
> > Thanks.
> >
> > Aaron
> >
> > > Gerald
> > >
> > >
> > > -------------------------------------------------------------
> > > Gerald Richter ecos electronic communication services gmbh
> > > Internetconnect * Webserver/-design/-datenbanken * Consulting
> > >
> > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> > > E-Mail: richter@ecos.de Voice: +49 6133 925131
> > > WWW: http://www.ecos.de Fax: +49 6133 925152
> > > -------------------------------------------------------------
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org