W3C home > Mailing lists > Public > www-html@w3.org > January 2000

RE: Preventing Refer field from being sent by browsers?

From: Dave J Woolley <DJW@bts.co.uk>
Date: Mon, 10 Jan 2000 11:38:17 -0000
Message-ID: <81E4A2BC03CED111845100104B62AFB53F3F4F@stagecoach.bts.co.uk>
To: www-html@w3.org
> From:	Ted Cohn [SMTP:ted@surveysez.com]
> Is there a way to prevent browsers from passing on a Referer field based
> on
> headers from the cgi that produced the HTML that contains the link?
	This is an HTTP question, not an HTML one.  If you are 
	specifically referring to parameters, note that Lynx suppresses
	these in Referer anyway.  Also note that at least one 
	popular web log analysis program uses this information to
	produce reports on which search engine keywords were used.

> We have discovered that some sites prevent displaying their original
> contents if there is a Referer field whose URL does not match its own
> site!
	This is done to prevent deep linking (links to other than
	the home page) which many commercial sites consider to reduce
	the value of their sites to themselves.  How to do this is,
	I believe, commonly requested information by site developers.
	Any complete blocking of Referers is likely to leave you on the
	losing side of the war, as most users have no awareness of the
	Referer issue, so content providers can afford to lose the
	business from those who do.

	Lynx users have found that some sites reject accesses which 
	don't include parameters.

> We have issues of privacy to prevent users of our service from being
> tracked
> having come from our site.
	If you are actually getting accesses blocked because of
	Referer, you are either deep linking in contravention of the
	terms of use of the site, or you are a search engine and the 
	site has failed to use robots.txt to enforce its deep linking
	policy, or you have ignored it.

	Basically, though, it is up to the user, or the user's service
	provider's proxy, to block Referer.
Received on Monday, 10 January 2000 06:42:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:52 UTC