[ic] mv_no_session causing weird scratch behavior

Grant emailgrant at gmail.com
Mon Jul 10 13:57:01 EDT 2006


> >> > I'm setting some scratch variables via [seti] that aren't carrying
> >> > over to the next page until I add an item to the shopping cart.  Then
> >> > it works as expected.  I'm using mv_no_session and when I turn that
> >> > off it works as expected from the start of the session.  Does this
> >> > make sense to anyone?  My browser has cookies enabled and I'm using IC
> >> > 5.2.
> >>
> >> If you're using mv_no_session, you have no session. The scratch variables
> >> are being set in a session that's never saved to disk. You can't have
> >> both. :)
> >
> > Can you tell me a little more about the implications of this?  I
> > thought mv_no_session just relied 100% on session cookies instead of
> > URL strings.  Should [set] and [seti] only start saving scratch
> > variables beyond the current page once an item is added to the
> > shopping cart with mv_no_session?
>
> Grant,
>
> I should ask you for more detail about what you mean by "I'm using
> mv_no_session". What exactly are you setting, and how?
>
> Jon

I'm using:

ScratchDefault mv_no_session 1

in catalog.cfg.

I'd love to get something cleared up.  There seems to be some
confusion about mv_no_session_id and mv_no_session.

First of all, what does mv_no_session_id do?  It does not remove the
session id from the URL as its name implies.  I can verify this myself
and here's a post describing the problem:

http://www.icdevgroup.org/pipermail/interchange-users/2003-February/031400.html

Secondly, what does mv_no_session do?  I think it simply removes the
session id from the URL to put the session burden completely on the
session cookie.  Jon, here's a post of your's, to me, recommending
mv_no_session for this purpose:

http://www.icdevgroup.org/pipermail/interchange-users/2005-January/041915.html

[set] variables should still persist from page to page with
mv_no_session, but they didn't for me until now.  After working on
this all morning I narrowed the culprit down to [set-cookie] when it
is used with a bad expire date.  I think this is a bug so I'm going to
post a new thread about it.

- Grant


More information about the interchange-users mailing list