Re^2: Getting the http referer

There are also some browsers which have an option to supress the referrer. (It used to be that they were way too liberal with information given -- the early versions of Netscape used to send your e-mail address with every request, and the referer header with whatever the last page you were on, even if it you weren't following a link.)

You might want to try a different browser, and see if you continue to have the same problem. Oh -- and the correct spelling is the misspelled one -- %ENV{'HTTP_REFERER'}. You can check all of the variables that you have to work with something like:

warn map { sprintf "%20s : %s\n", $_, $ENV{$_} } sort keys %ENV;

(will send to your webserver's error log, unless you've changed where ~~STDOUT~~ STDERR goes)

Update: STDOUT != STDERR. (shouldn't post before I've had my morning caffeine.. thanks manav for the catch)

Comment on Re^2: Getting the http referer Select or Download Code

Replies are listed 'Best First'.
Re^3: Getting the http referer by manav (Scribe) on Mar 15, 2005 at 12:28 UTC
Not STDOUT but STDERR.... Manav	[reply]
Re^3: Getting the http referer by Delusional (Beadle) on Mar 21, 2005 at 08:49 UTC
Thanks. I located the problem. The issue was with the site being in frames, and the code to grab the info, was in a framed page, thus I was getting the site as a refered since the main frame page was calling the sub html/cgi. Putting a SSI call to a cgi script to get the info works fine. Any chance someone knows how i can set a new var to the browser so that all page calls will have the info, without using a dummy form?	[reply]
Re^4: Getting the http referer by jhourcle (Prior) on Mar 21, 2005 at 11:12 UTC
Ah...frames. I've been avoiding frames for about 6 years, mostly because of this problem. I don't know how current browsers handle the issue, but in the IE4/Netscape4 days, one of them would list the HTTP_REFERER for a frame as the frameset page. The other one would list it as the page that referred to the frameset page. This made it particularly difficult to get accurate site statistics, and to perform simple tests to see if someone had tried bypassing the frameset page, and to force a reload. In one of the browsers (I think it was IE), this would result in the frameset being redirected to the frameset, and a nasty loop starting. (Even when playing with it in JavaScript, setting it to override the top content, so it'd break out of other frames, I ended up never ending cycles.) The main reason for frames, originally, was the reduction of bandwidth required for a site. It also helped with reducing the amount of repetitive HTML needed in pages, which should have saved authoring time, but the many flaws in its implementation have reduced any significant savings. These days, you'll probably spend your time better by using SS, templates, CGI, or text-preprocessors to generate the pages to reduce authoring time, and CSS in a shared file to reduce the size of the formatting of frames. Due to the limitations with frames, I would probably only use them these days if I knew I could control which browsers and users were accessing the site. (which leaves us with administration-only pages, and/or intranet sites). Now that I've bitched about frames -- solving your problem. I know of only four ways -- passing the info in PATH_INFO or QUERY_STRING, (where the frameset can insert it) problem: anyone else can set it, too, or link directly to the page, so depending on your reasoning for needing it, it's probably useless. time-sensitive URLs. (have the frameset add a timestamp in PATH_INFO or QUERY_STRING) I've never tried it, so I don't know how it might affect bookmarks, or people revisiting the page after the timeout. And of course, someone could reverse engineer the timestamp. Either of the two above, but use cookies. Lack of support for people rejecting cookies. Some organizations have policies forbidding their use. Establishing and tracking individual sessions for each user. Higher overhead You'd have to decide for yourself if the advantages of frames outweigh the problems.	[reply]