Referer Refresher
By Lincoln D. Stein
Recently I received two emails arriving within hours of each other. The first was a bug report from a Webmaster who was concerned that Netscape's and Microsoft's implementations of the HTTP Referer header were causing credit-card numbers and other confidential information to be disclosed to third parties. The second was an anguished cry from another Webmaster who had recently learned that Microsoft Internet Explorer 4.0 tightens restrictions on referrer information by disabling the header under certain conditions. Both authors were convinced that they had uncovered major security holes. The first felt that the Referer mechanism poses an unacceptable security risk by leaking information from one site to another. The second saw the Referer field as an essential tool for guaranteeing the integrity of fill-out forms and defeating Internet fraud. They couldn't both be right. Could they?
A Referer Refresher
The Referer field has been with us since HTTP/1.0. It's an optional header field that contains the URL of the referring document. In the case of a hypertext link, the referring document is the page that contains the link. In the case of an in-line image, sound, or applet, the referrer is the document in which the in-line image appears. Most Web servers offer an option to log the referrer information, either to the main access log or to an auxiliary file.
There's no standard for recording referrer information, but many NCSA-derived servers often use a separate file named "referer_log" with lines like the one shown in
