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@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>
A fix for <rdar://problem/4965133> was committed in r19553.