[ic] Interesting Failure Reading Scratch Variables from Session
John Beima
interchange-users@icdevgroup.org
Wed Jul 17 23:45:00 2002
Quoting John Young <john_young@sonic.net>:
> I wrote:
>
> > >Here's a funny one that may already be known, or perhaps some value as an
> FYI:
> > >
> > >Newer browsers seem to consistently fail in updating scratch variables
> > >stored in a session file when some other delivery failure (in this case a
> missing
> > >image file) occurs; yet Netscape 4.61 does not. Details below for
> anyone
> > >interested. I'm not having a problem with this, because I will insure
> that
> > >I don't have any missing images. It's just a little curious (and I hope
> that
> > >I am coding things properly). I also don't consider this a bug... just
> a
> > >behavior anomaly.
> ...[quoted details omitted]...
>
>
> Ed LaFrance replied:
> > Unless you are using IC as an http server, which I have heard rumor is
> > possible, IC completes all its processing before handing off output to
> > Apache, so I don't see how a broken image link could have any bearing on
> > IC's correct function. What's more, I have ample first-hand experience with
>
> > a variety of browsers and a wide range of server configurations to back
> > this up.
>
> Good point. However, when the complexities of IC, Apache, browsers,
> etc. are summed, I believe it is quite possible that a broken image link
> could indeed affect IC's function in subtle ways. Such is the nature of
> complex, full-featured applications.
>
> What I believe is going here, is that the newer browsers are perhaps
> triggering an error signal that the older browser is not, and IC is
> reacting
> differently to the those signals. With additional logDebug's enabled,
> I've discovered that broken links coupled with a newer browser generates:
>
> Vend::Server:debug: redo accept on error=Bad file number n=1 v= p= unix=
> pid=1437 c=11 i=2
>
> yet the older browser, even with broken links, does not.
>
> I've also found that the variable I was trying to save to the session was
> actually
> being saved in the initial session, but IC is switching to another session as
> soon
> as the broken links are encountered ...while using a newer browser.
>
> One can see below that in the first example, with broken links, IC
> establishes a
> new session at line #75. Yet with unbroken links in the following example,
> one
> can see that the original session is continuing to be used at line #77.
>
> Newer browser + broken links:
> 70 Vend::Session:debug: delete TmpScratch=control_index
> 71 Vend::Session:debug: delete TmpScratch=control_index
> 72 Vend::Session:debug: delete TmpScratch=control_index
> 73 Vend::Session:debug: try to close session id=TuwK26Hu
> name=TuwK26Hu:192.168.0.4
> 74 Vend::Session:debug: close session id=TuwK26Hu
> name=TuwK26Hu:192.168.0.4
> > 75 Vend::Session:debug: new session id= name= seed=
> 76 Vend::Session:debug: open_session: File_sessions=1
> Sub=CODE(0x514c8c)
> 77 Vend::Session:debug: name session user= host=192.168.0.4
> (192.168.0.4)
> 78
> 79 Vend::Session:debug: name session id=uLG79qXa
> name=uLG79qXa:192.168.0.4
> 80
> 81 Vend::Session:debug: init_session uLG79qXa:192.168.0.4 is: {
> 82 'values' => {
> 83 'country' => 'US',
> 84 'mv_shipmode' => '2DA'
> 85 },
> 86 'ohost' => '192.168.0.4',
> 87 'carts' => {
> 88 'main' => []
> 89 },
> 90 'scratch' => {
>
> Newer browser + unbroken links:
> 70 Vend::Session:debug: delete TmpScratch=control_index
> 71 Vend::Session:debug: delete TmpScratch=control_index
> 72 Vend::Session:debug: delete TmpScratch=control_index
> 73 Vend::Session:debug: try to close session id=xPIWADWX
> name=xPIWADWX:192.168.0.4
> 74 Vend::Session:debug: close session id=xPIWADWX
> name=xPIWADWX:192.168.0.4
> 75 Vend::Session:debug: name session user= host=192.168.0.4
> (192.168.0.4)
> 76
> > 77 Vend::Session:debug: name session id=xPIWADWX
> name=xPIWADWX:192.168.0.4
> 78
> 79 Vend::Session:debug: session name now xPIWADWX:192.168.0.4
> 80 Vend::Session:debug: open_session: File_sessions=1
> Sub=CODE(0x50d0ac)
> 81 Vend::Session:debug: read session id=xPIWADWX
> name=xPIWADWX:192.168.0.4
> 82
> 83 Vend::Session:debug: Session:
> 84 HASH(0x1256214)
> 85
> 86 Vend::Session:debug: write session id=xPIWADWX
> name=xPIWADWX:192.168.0.4
> 87
> 88 Vend::Session:debug: delete TmpScratch=page_title
> 89 Vend::Session:debug: delete TmpScratch=control_index
> 90 Vend::Session:debug: delete TmpScratch=control_index
>
> Once again, I don't see this as a big problem (after all, we should all keep
> things
> tidy and not have broken links). But I am, however, slightly curious about
> it from
> the standpoint of potential situations where sessions might be switched when
> one
> isn't counting on it (a rare enough possibility as to not be cause for
> concern).
> I suppose this also further supports the validity of testing with multiple
> browsers.
>
>
> Christopher F. Miller chimed in:
> > Another case of a bug report without sufficient data, eg the code from
> > the page in question. Did you weblint the page? Check quoting.
>
> Hmmm... As I mentioned in my original message, I do not consider this a bug
> at this
> point. BTW, weblint does not turn up anything - the page setting the
> variable is very,
> very simple. Perhaps the information above is closer to being sufficient
> data, and if
> not, I have some multi-megabyte icdebug files I'd be happy to email to you
> off list... ;-)
>
> No, I was initially just hoping that someone more familiar with sessions at a
> low level
> might comment if this stirred something in their mind. If not, no biggy.
>
>
> BTW, this can easily be tested. Using the following data on your ic
> server,
> retrieve with a newer browser and an older browser if you have it the
> following files in this order:
>
> test_putvar.html
> test_getvar.html (should show ABC)
> test_putvar_noimage.html
> test_getvar.html (should fail to show DEF on newer browser because the
> session switched)
>
>
> test_putvar.html:
> ---------------------------------------------------
> <html>
> <body>
>
> [set whatever]ABC[/set]
> <p>
> This is a test.
> </p>
>
> </body>
> </html>
> ---------------------------------------------------
>
> test_getvar.html:
> ---------------------------------------------------
> <html>
> <body>
>
> <p>
> This is a test - retrieve the value:
> [perl]
> $Scratch->{whatever};
> [/perl]
> </p>
>
> </body>
> </html>
> ---------------------------------------------------
>
> test_putvar_noimage.html:
> ---------------------------------------------------
> <html>
> <body>
>
> [set whatever]DEF[/set]
> <IMG SRC="/im_not_here.jpg">
> <p>
> This is a test.
> </p>
>
> </body>
> </html>
> ---------------------------------------------------
>
> -John Young
> _______________________________________________
> interchange-users mailing list
> interchange-users@icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>
Actually your test shouldn't show ABC... It is done wrong...
[set test]ABC[/set]
[perl]
my $out = '';
$out = $Scratch->{test};
return $out;
[/perl]
Would return an output of you scratch variable. Not what you are doing.
Also I can tell you ALL of our sites rely HEAVILY on scratch variables and even
hopping back and forth between two different domains when going in and out of
SSL. One of our sites does in fact have a broken images link on of the SSL
pages, which I am too busy to fix. It has had ZERO effect on the 20+ scratch
variables being maintained and accessed.