[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