[Webkit-unassigned] [Bug 12657] New: REGRESSION: WebKit sends internal referrers

Tue Feb 6 23:25:57 PST 2007

http://bugs.webkit.org/show_bug.cgi?id=12657

           Summary: REGRESSION: WebKit sends internal referrers
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Keywords: InRadar
          Severity: Normal
          Priority: P1
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mjs at apple.com

2007-01-30 15:28:44 Sean MacMillan:
WebKit seems to have changed to send 'internal' referrer information out to
servers when used in applications.

For example, in NewsFire, I see that URLs like
"applewebdata://7FAEA055-ABF2-486B-975F-607F40D28886" are sent to the web
server when images of an RSS item  are requested.

This is a change in the behaviour of WebKit. And I think it's a problematic
one. Problematic because I (and numerous people I know) protect their server
bandwidth by denying image requests to the server if the referrer for that
request is not in the server's own domain. So far the request used in NewsFire
for example were blank. And usually people configure their server to accomodate
such requests with a blank referrer. But with the new strategy of sending an
applewebdata referrer along with the request, this looks like a hostile request
at first and the images aren't sent. 

While I can quickly adjust my .htaccess rules to take care of this problem, I
guess it'd be better if the problem didn't come to existence to begin with.

*VERSION: 9A343
*OCCURRED IN PREVIOUS RELEASED VERSION: No

*REPRODUCTION STEPS: 
1. Run News Fire
2. Subscribe, for example, to http://www.blogography.com/atom.xml
3. Look at the images in the posts

=> you'll see "don't steal my bandwidth" images

*EXPECTED RESULTS: 
The images appearing on page as intended

*ACTUAL RESULTS: 
"Don't steal my bandwidth" images appearing instead.

*ISOLATION: 
I checked my server logs and noticed the change in referrer data sent by
NewsFire which is causing this problem.

From: Sven-S. Porst <ssp-shop at earthlingsoft.net>
Sonar Request ID: 24468437
sonr://request/24468437
Seed Project: seedx
Seed Project ID: 1000327
Submission ID: CFE83275-68E8-49DC-B068-161BA18A2041

2007-02-04 00:32:14 Brady Eidson:
Since 9A343 we've fixed up more and more of the loader code and we no longer
will send applewebdata referers - however, we're now sending about:blank -
still a problem!  Probably an easy fix

2007-02-04 02:00:41 Brady Eidson:
I think sending about:blank as a referer is silly.  Maciej didn't dismiss it as
easily as myself, however, and recommended a test of Safari vs FireFox akin to
the following -

<html>
<script type="text/javascript">
function writeImage()
{
document.write("<img src=\"http://www.blogography.com/face/hmm.gif\"/>");
}
</script>
<body>
<iframe name="hello" src="about:blank" onLoad="writeImage();"></iframe>
</body>
</html>

Running the above test in ToT Safari, we *do* send the about:blank referer and
the image comes back with an anti-leech message.
Running the above test in Firefox sends *no* referer - and the image displays
successfully.

Therefore, I renew my claim that about:blank should mean we hide the referer
and will discuss it further with him tomorrow.

2007-02-04 08:39:57 Maciej Stachowiak:
I think your test has a bug. Instead of document.frames["hello"].document.write

2007-02-04 19:28:01 Brady Eidson:
I agree.  Though I couldn't get document.frames to work...  this following
example does work in both ToT and Firefox - 
<html>
<script type="text/javascript">
function writeImage()
{
  var frameObj = document.getElementById("hello");
  frameObj.contentWindow.document.write("<img
src=\"http://www.blogography.com/face/hmm.gif\"/>");
}
</script>
<body>
<br>Before iFrame<br>
<iframe id="hello" src="about:blank" onLoad="writeImage();"></iframe>
<br>After iFrame<br>
</body>
</html>

This case shows ToT loading the anti-leech image into its subframe, and FF
loading the correct one.  tcpflow confirms ToT Safari sends the file:// url as
a referer in this case, but FF still sends no referer

<rdar://problem/4965133>

-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.