Announcement

**Golf Tee Warehouse** · 05-Aug-2009, 08:04 AM

I have still not made any progress with this.

I have checked Google Analytics for August which shows 126 page visits for the basket (/cgi-bin/ca000001.pl) and the number of cgi-bin related 'Required but not found URLs (HTTP code 404)' in my stats is between 82 and 117 for Aguust so far.

No other page is above 2 errors

**pinbrook** · 05-Aug-2009, 09:22 AM

I thought perhaps a relative URL problem in the basket / checkout pages but cannot see anything obvious.

its that type of problem, somewhere on the site there is a url being generated that goes via cgi-bin

**Golf Tee Warehouse** · 05-Aug-2009, 12:20 PM

I think I have found the cause but unsure yet how to fix it. When I have time later I will do a bit of searching on the forum.

Checking the source code I see the following:

Home Page:

Code:

src="acatalog/actinicextras.js"

Product Pages:

Code:

src="actinicextras.js"

Cart Pages: Home Page:

Code:

src="actinicextras.js"

So obviously from any pages such as the cart in the cgi-bin folder with relative urls the browser is looking at www.mysite.co.uk/cgi-bin/actinicextras.js" instead of www.mysite.co.uk/acatalog/actinicextras.js"

Is this likely to involve changes in the network settings or just a change to the relative URL

EDIT: The above comments are wrong as I have now realised that the
BASE HREF = "http://www.golfteewarehouse.co.uk/acatalog/"> so points to the correct loaction.

**pinbrook** · 05-Aug-2009, 12:26 PM

you could post your network settings here

or if you do not have ssl on the site, just hard code the links.

or use a 404 page not found in htaccess to redirect all 404s to the index page

often loss of relative links is down to baseref but that looks ok, so it is abit of an oddity

**Golf Tee Warehouse** · 05-Aug-2009, 12:28 PM

Was just in the process of posting them:

HTTPPROXYMODE 0
HTTPPROXYADDRESS
HTTPPROXYPORT 80
HTTPPROXYUSER
HTTPPROXYPASSWORD
FTPPROXYMODE 0
FTPPROXYADDRESS
FTPPROXYPORT 21
FTPPROXYUSER
FTPPROXYPASSWORD
SCRIPTID 1
SCRIPTEXT .pl
SMTPHOST localhost
WEBSITEURL http://www.golfteewarehouse.co.uk
IGNOREPASSIVEERRORS true
USERELATIVECGIURLS false
PATHTOPERL /usr/bin/perl
USEENHANCEFTP true
FTPCLIENTTIMEOUT 15000
FTPRETRYDELAY 3000
FTPKEEPALIVEINTERVAL 30000
FTPSILENT false
FTPMAXRETRIES 3
FTPCONNECTTIMEOUT 25000
SMTPAUTHREQUIRED false
SMTPUSERNAME
SMTPPASSWORD
COMPRESSIONPACKETSIZE 1024
COMPRESSEDUPLOAD true
CATALOGURL http://www.golfteewarehouse.co.uk/acatalog/
ONLINESTOREFOLDERNAME acatalog
CGIBINURL http://www.golfteewarehouse.co.uk/cgi-bin/
PATHFROMCGITOCATALOG ../acatalog/
CODEBASE ./
FTPHOST ftp.golfteewarehouse.co.uk
FTPUSERNAME *****
FTPPASSWORD *****
PATHTOCGIBIN public_html/cgi-bin/
USEPASSIVEFTP false
FTPPATHFROMCGITOCATALOG

I do not use SSL

**Golf Tee Warehouse** · 05-Aug-2009, 01:44 PM

Is there anything wrong with any of the BASE HREF lines of code which seems to change depending on whether you are on the homepage, product page or cart pages.

Homepage:

Code:

<Actinic:BASEHREF VALUE="http://www.golfteewarehouse.co.uk/" FORCED=1 />

Product Pages:

Code:

<Actinic:BASEHREF VALUE="http://www.golfteewarehouse.co.uk/acatalog/" FORCED=0 />

Cart Pages:

Code:

<BASE HREF="http://www.golfteewarehouse.co.uk/acatalog/">

The cart pages do not have Actinic: at the start and has a space between BASE and HREF

**pinbrook** · 05-Aug-2009, 01:56 PM

in my layouts i have

Code:

<Actinic:BASEHREF VALUE="<Actinic:Variable Name="CatalogURL"/>
"/>

i have one outer layout for the checkout and one for the rest but the basehref is the same

**Golf Tee Warehouse** · 05-Aug-2009, 02:15 PM

I have compared by basehrefs to one of Lee's websites and they look exactly the same so I assume that is not the cause.

If nobody can see anything obvious with the network settings I will try the hardcoded links option and see what effect it has on the stats page over the net couple of days.

It seems strange that only cgi-bin/ca000001.pl is listed on the stats page as the referrer causing the problem and not cgi-bin/os000001

Is changing the script ID worth a try?

I could but a blockif around the script links for Normans scripts to stop the link being shown on the basket page as they are not required, unsure about blocking out actinicextra.js though without investigating what is does in more detail.

P.S. The problem itself does not actually appear to have any consequences other than appearing as errors on my hosting stats page, although a little worried that some buyers might see some sort of error message which could be off-putting it did occur.

**Golf Tee Warehouse** · 07-Aug-2009, 02:58 PM

UPDATE: All seems to be fixed now, the last 2 days worth of stats show no new CGI-BIN 404's, although I have no idea what fixed it, I obviosuly made a small change somewhere.
I did do a full site refresh but that was half way through the first day so if that fixed the problem I would have expected to see reduce numbers rather than none.

**Golf Tee Warehouse** · 11-Aug-2009, 08:11 AM

UPDATE: Seems I was a bit premature thinking I had fixed the problem, I now realise that I had added a custom 404 error page which was then listing all 404 errrors as '302 Moved temporaily (redirect)'.

So I am now back on the search for the cause of these errors.

As the referring page is listed as http://www.mydomain.co.uk/cgi-bin/ca000001.pl am I correct in looking at the 'view basket' page for the problem.

The source code on this page gives contains the code below which to me looks correct.

Code:

<BASE HREF="http://www.golfteewarehouse.co.uk/acatalog/">

<script language="javascript" type="text/javascript" src="actinicextras.js"></script>

Also why would adding

ErrorDocument 404 http://www.golfteewarehouse.co.uk/ac.../404_Page.html

to the htaccess file cause AWSTATS to list the 404 errors as 302 errors, is this normal. The full contents of the htaccess file is shown below, although I have now removed the custom 404 line until I solve the first problem.

Code:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^golfteewarehouse.(.*)
RewriteRule ^(.*)$ http://www.golfteewarehouse.co.uk/$1 [R=301,L]
Redirect 301 /acatalog/XT1Tees.html http://www.golfteewarehouse.co.uk/acatalog/XT1_Golf_Tees.html
Redirect 301 /acatalog/test/ http://www.golfteewarehouse.co.uk/
ErrorDocument 404 http://www.golfteewarehouse.co.uk/acatalog/404_Page.html

As I have said before these errors do not seem to be causing a problem to the site other than creating large error counts in the stats.
Any suggestions would be most welcome.

**Golf Tee Warehouse** · 13-Aug-2009, 06:02 PM

I still have yet to solve this problem, and decided to go with Jo's suggestion of hardcoding the links, but the hardcoded links don't seem to work reliably.

To test the changes I used Normans collapso-5.js script as it is the easiest to test, as the menu doesn't open and close if the javascript file isn't found, so I changed

Code:

<script language="javascript" type="text/javascript" src="collapso-5.js"></script>

to

Code:

<script language="javascript" type="text/javascript" src="http://www.golfteewarehouse.co.uk/acatalog/collapso-5.js"></script>

The result is that it sometimes works fine but others times it doesn't (even on the same PC and browser) and I receieve a javascript error in the bottom left had corner stating I have an error on line 215 (or 200) which equates to the position of some code related to Normans Collapso menu script, so I assume that the browser is not finding the javascript file.

Have I done anything obviously incorrect.

P.S. I have reverted back to relative URL's for now as this is on a live site.

**Golf Tee Warehouse** · 20-Aug-2009, 08:45 AM

After wasting many hours over the last 2 1/2 weeks trying to find the cause of this error I decided to analyze the visitors logs in cpanel and noticed that after the browser sends a GET command for the scripts from the CGI-BIN folder it then follows up by trying the correct location which is why every looks ok to a customer.

On further investigation I noticed that there was a correlation between the 404 errors and the IE8 browser, so decided to make a test purchase using IE7 and then again 5 minutes later with IE8 and on checking the log files I found that only the IE8 browser visit produced any 4040 errors.

A quick google for base href IE8 brought up a known IE8 bug in IE8's Lookahead Downloader where the browser looks for objects in the current directory before and in addition to the folder specified in the base href tag.

http://social.msdn.microsoft.com/For...5-88b660f3e1ca
http://blogs.msdn.com/ieinternals/ar...ownloader.aspx

I assume that this would effect most Actinic users.

EDIT: This has now been fixed in a IE8 cumulative update - Mid Oct'09

**cobbler** · 02-Sep-2009, 12:17 PM

[QUOTE=Golf Tee Warehouse;281404]
Also why would adding to the htaccess file cause AWSTATS to list the 404 errors as 302 errors, is this normal. The full contents of the htaccess file is shown below, although I have now removed the custom 404 line until I solve the first problem.QUOTE]

I know it's a bit late, but I came across this thread while I was researching my own 404 problem. (I won't go into detail here because I don't want to hijack the thread), but suffice to say I can tell you that, apparently, using a full url in the .htaccess file will give a "soft" 404. This is when the correct 404 page is displayed, but with a 302/200 response code.
You need to use a relative url to get the correct 404 response code: ErrorDocument 404 /404_page.html (or something similar)

hope that helps a little. I'm going to have to start a new thread to try and sort my own particular problem out!

Announcement

CGI-BIN - 404 Error Codes

CGI-BIN - 404 Error Codes

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment