Bizarre CGI-Bin related error...

[Marci]

I had no cgi-bin navigation errors even from the www.home page (now there is a mention of www - it's the home link on the top menu - which means the bottommost setting on the network setup page - usually).

Home link is a hardcoded link, nothing generated by Actinic... as bottom-most setting on Network Settings is set to http://store.over-clock.com

I added to cart, progressed to page 2 of checkout and came back to view cart to remove my items (I had to look for the buttons - and only did because I knew they should be somewhere on the page - they really should be directly under the cart).

Bearing in mind I'm seeing it here with NO stylesheet info, I'm not quite sure what you mean... can u screencap it??

EDIT: Found & Fixed that bit - ta fer pointing it out!

[Marci]

*sigh* bloody browser cache. After ditching cache for 3rd time this morning, all now appears to work correctly. Is there anyway to insert some code into script-related pages ONLY to disable caching of CGIScripts?

[Marci]

*bangs head on wall*

After days of working fine, all of a sudden the problem reoccurs - turns out to be related to referrer. Basically, when accessing any of the CGI pages, the REFERRING URL becomes the base href... and it's this that keeps randomly cockin' stuff up.

[Marci]

Righty... here's where I'm at.

Went to www.over-clock.com/ivb this morning, clicked the contactus link, which links thru to Actinic's ContactUs page.

No stylesheet data displayed. Went to "View Source" and the <base href> field was set to <BASE HREF="http://www.over-clock.com/ivb/">

This PC has now cached that, so now no matter where I attempt to go to one of the store's CGI Scripts from, it always shows with no stylesheet data and 404's out on links due to this incorrect basehref field that appears to be being subsituted for the referring page by one of (or all of) the perl scripts.

SOooo, in an attempt to combat this, have gone and appended &ACTINIC_REFERRER=CatalogURL to the end of all such links, & emptied cache & cookies etc thinking that this MUST be the solution... but it isn't. View Source still shows it set to "www.over-clock.com/ivb/"
Ditto if I append &BASEURL=CatalogURL to links also

I can also now confirm that my customers are seeing this problem too: http://www.over-clock.com/ivb/index.php?showtopic=19992

I suspect the cause of this issue is also the cause of this fella's problem too: http://community.actinic.com/showthr...light=referrer

[Marci]

This PC has now cached that, so now no matter where I attempt to go to one of the store's CGI Scripts from, it always shows with no stylesheet data and 404's out on links due to this incorrect basehref field that appears to be being subsituted for the referring page by one of (or all of) the perl scripts.

Scratch that - the PC hasn't cached it... it's cookied it. Joys of tabbed browsing, the "session" doesn't end til you kill the browser, not the tab hence much tail chasing. If I empty cache, there's no change. If I empty COOKIES however, then it finally ditches the original referrer as Basehref, and replaces it with string-enforced via &actinic_referrer... so... why is the referring url being written to a cookie?? Why not have a further setting in Network Settings or similar to hard-code the BASE HREF for scripts permanently to the StoreURL rather than having to define it as a URL String??

Long n' short... reupload site with all external links ending with &ACTINIC_REFERRER=[Your Catalog URL], remove offending cookie and cache. Restart Browser. Job Done.

[Marci]

And NOW I remember why we ran a split store... with cgi-bin on www. and everything else on store.

Flippin' SharedSSL is tied to www. and couldn't be arsed getting it changed to store. so fudged a way round it in Actinic. Sods law, our checkout has been down since changing cgi-bin over to store.over-clock.com last thursday. No-one here at work thought to tell me there'd been no orders, and none of our customers tried to inform us either (til now)... my own fault for not doing a full test-order...

Have just phoned thru to get SharedSSL changed over to store. and then hopefully that's finally everything tickety-boo...

Have edited OP with description of solution & link to my last few posts detailing it further.