Please note that such wrappers should produce normal HTML pages with
hyperlinks and HTTP-EQUIV "client pull" tags. If the wrapper simply uses a
Location: redirect, many clients will send the URL of the original page,
not the URL of the intermediate wrapper (verified in Netscape 4.7 and MSIE
4.0). For things like this click-through wrapper, this behavior[0] is
important to understand.
E.G.
Example 1:
http://mail.example.com/foo
contains link to http://mail.example.com/redir?http://example.org/
http://mail.example.com/redir?http://example.org/
uses Location: to redirect client to http://example.org/
http://example.org/
sees HTTP_REFERER as "http://mail.example.com/foo"
Example 2:
http://mail.example.com/foo
contains link to http://mail.example.com/redir?http://example.org/
http://mail.example.com/redir?http://example.org/
creates HTML page with
<META HTTP-EQUIV=refresh CONTENT="1; url=http://example.org/">
http://example.org/
HTTP_REFERER is either empty[1] or contains
"http://mail.example.com/redir?http://example.org/"
Which also means you probably want to be careful what your wrapper
puts in the CONTENT attribute of the client-pull tag. Of course all
this depends on the behavior of the browser. ;-) Happy coding,
-Peter
http://www.bastille-linux.org/ : working towards more secure Linux systems
[0] This allows helpful/good things like browsers telling what the last
page really was when the user follows a server side image map; having a
referer like http://bignewssite.example.com/headlines.map?1,2 is not as
helpful as http://bignewssite.example.com/daily/12jan/sportsnews.html
[1] For Netscape 4.7 and MSIE 4.0, if the user's browser follows the
client-pull META tag, the browser will not send *any* Referer header to
http://example.org/; but if the wrapper creates a normal <A HREF="...">
hyperlink, the browser will send the URL of the wrapper to the server
handling http://example.org/. So a client-pull with a short delay in the
CONTENT attribute is most likely to anonymize the hyperlink.
At 8:48am Jan 12, 2000, CDI wrote:
> [2] A wrapper implementation looks at each incoming email. Any link found in
> the email which leads offsite will be "wrapped". An example;
>
> original: http://www.example.com/
> wrapped : http://www.cp.net/cgi-bin/wrapper?http://www.example.com/
>
> The wrapper CGI in this instance foils the Referer bug by changing the
> Referer to itself. In most cases, the resultant referer is identical to
> the 'wrapped' URL shown above. This method of preventing the bug is
> effective, but certainly not perfect.
