Forum Moderators: DixonJones

Message Too Old, No Replies

Calls to htc files result in mulitple "referrals"?

why is the PREVIOUS page listed as the referrer?

         

bruhaha

9:10 pm on Feb 9, 2004 (gmt 0)

10+ Year Member



This may ultimately be a coding issue, but the problem appears in the logs, and perhaps it can be solved there as well. . .

Some of our web pages have sortable tables, which use an IE behavior (using an .htc file). The file is called in the header, thus:

<style type="text/css">
.sort {
/* BEGIN $SORT_BEHAVIOR$ */
behavior: url(sort/sort.htc);
/* END $SORT_BEHAVIOR$ */
}
</style>

This file is called for by one or more tables on the page by use of "class":
<table class="sort">

The tables sort fine. The problem is this:

EVERY time the page calls the "sort.htc" file, the logs record a "referral" not from the current page (with the table), but from the PREVIOUS page the visitor used to get there. If someone was referred to the page from a search engine, the logs end up recording several "referrals" to our site from that SE, using the same search term, when in fact, there was only ONE referral.

Any ideas why this happens or what I can do to prevent it?

(I discovered this when someone got to one of these pages using a very unusual search term. I knew 10 people had not gotten to our site using THAT term.. and on the same day!)

bruhaha

2:10 pm on Feb 10, 2004 (gmt 0)

10+ Year Member



Well, I found something of an answer.

Microsoft's Knowledge Base includes an article(#319176):
"BUG: Cached HTC Files Generate Unnecessary GET Requests"

Under "Symptoms" they write:
"After a Hypertext Markup Language Component (HTC) file has been cached on a client computer, requests after that to use the file may result in an unnecessary extra If-Modified-Since GET request to the server even though the file has not expired."

Their solution? Ignore it; it has 'minimal effect' on performance. They also say that manually setting the content expiration date does nothing to change this behavior.

In short --NO solution to the problem of inaccurate referral records.

So, does anyone have an idea of how I can help the logs "get it right" (short of post-processing to eliminate the extra lines?)