2013-02-05 25 views
10

我們經營一個網址縮短服務,在過去的一週左右,我們已經開始看到大量奇怪的請求爲{normal url}/no_facebook_preview_picture.jpg從Facebook擁有的IP地址和用戶代理{URL} /no_facebook_preview_picture.jpg Facebook的請求facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)對404個鏈接

如果我張貼在牆上正常鏈接到我們的網站(設爲Only Me所以我可以測試),我得到了我們的訪問日誌

66.220.152.6 - - [05/Feb/2013:16:31:36 +0000] "GET /44_U HTTP/1.1" 200 1314 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

但是下面的條目,如果我張貼返回404或410的鏈接(創建垃圾郵件鏈接後刪除)我得到這個

69.171.237.15 - - [05/Feb/2013:16:49:16 +0000] "GET /notexistURL HTTP/1.1" 404 1319 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

然後在一小時內左右

173.252.110.113 - - [05/Feb/2013:17:15:15 +0000] "GET /notexistURL/no_facebook_preview_picture.jpg HTTP/1.1" 404 0 "-" "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

知識產權的域名註冊報告

NetName FACEBOOK-INC 
NetHandle NET-173-252-64-0-1 

所以他們肯定是Facebook的IP地址。

我們每天都會收到10-20個這樣的請求,全部完全相同。我們只能獲得價值7天的日誌文件,但這些請求在7天前發生。

我測試過的鏈接是唯一的,所以沒有其他方法可以找到任何鏈接。我並不親自使用Facebook,除了我的測試鏈接以外,其他用戶都創建/發佈了所有鏈接,但我承認所有鏈接到我的Facebook帳戶的應用程序並沒有什麼不尋常之處,所以我不認爲這是第三方應用程序(如果需要,我可以提供一個列表,但它們都是大名字應用程序)

在我檢查日誌文件期間,Facebook似乎沒有智能地創建這些請求,它只是盲目地粘住字符串/no_facebook_preview_picture.jpg甚至在使用查詢字符串的情況下也可以在URL的末尾。例如;

69.171.228.114 - - [05/Feb/2013:17:19:13 +0000] "GET /iAmNotARealURL1234777?ref=fb&cows_go=moo HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 
69.171.228.114 - - [05/Feb/2013:17:19:13 +0000] "GET /iamnotarealurl1234777 HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 
173.252.103.4 - - [05/Feb/2013:17:44:41 +0000] "GET /iAmNotARealURL1234777?ref=fb&cows_go=moo/no_facebook_preview_picture.jpg HTTP/1.1" 404 1118 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-" 

谷歌似乎顯示大量的隨機結果,大多是從發起人的鏈接,但我找不到任何信息,以什麼這些請求。

這些要求是什麼? Facebook需要他們什麼?這是我們應用程序中的錯誤還是可以安全忽略這些請求?

更新:

有些日子,現在我們正在2-3百命中這些URL

[[email protected] nginx]$ for DAYLOG in `find ./ | grep "dftbashort.log-"`; do COUNT=`cat $DAYLOG | grep no_facebook_preview_picture | wc -l`; echo "${DAYLOG} has ${COUNT} occurences"; done 
./dftbashort.log-20130201 has 0 occurences 
./dftbashort.log-20130130 has 2 occurences 
./dftbashort.log-20130129 has 2 occurences 
./dftbashort.log-20130128 has 2 occurences 
./dftbashort.log-20130202 has 378 occurences 
./dftbashort.log-20130207 has 222 occurences 
./dftbashort.log-20130205 has 257 occurences 
./dftbashort.log-20130209 has 178 occurences 
./dftbashort.log-20130131 has 2 occurences 
./dftbashort.log-20130203 has 266 occurences 
./dftbashort.log-20130206 has 667 occurences 
./dftbashort.log-20130204 has 12 occurences 
./dftbashort.log-20130127 has 4 occurences 
./dftbashort.log-20130208 has 260 occurences 

我們不提供任何開放式圖形meta標籤,頁面沒有內容除了meta/javascript重定向。

回答

2

我敢肯定這是共享刮板試圖建立您的網址預覽,通過Facebook's Debug Tool運行的網址,你會看到Facebook上看到的東西/尋找

我不知道是什麼/notexistURL/no_facebook_preview_picture.jpg請求是,假設您的代碼中沒有任何內容指向這樣的URL; 如果我不得不猜測,我會說這是某種默認或後備使用時沒有元標籤;可能是一個錯誤 - 我相當有信心,如果你爲Facebook包含正確的元標記,它會抓住這些元標籤,而不會發出無效請求,而在Facebook上你的URL分享的額外好處。com和其他支持相同標籤的網站

+0

是的,我瞭解Facebook的抓取工具,沒關係,我們從中得到很多點擊來擴大我們縮短的網址。自從我發佈這篇文章以來,我們現在每天都會收到數百個這樣的'no_facebook_preview_picture'網址請求(https://gist.github.com/samarudge/0c4a040c389c5b339278 – Smudge

0

今天早上我遇到了同樣的事情並做了一些挖掘。您可以使用this site處的信息來幫助您指引正確的方向。似乎有助於我的網站被這些錯誤殺死。

+0

)您的「答案」幾乎完全由外部鏈接組成。請[見這裏](http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers)進行一些與這些類型的答案有關的討論。 .. – Lix

+0

你好,網站所有者在這裏,可以向人們保證AgentPhoenix和我不是同一個人,我的博客文章是專門與SharePoint公共網站相關的,但有些截圖可能對人有用,我同意@Igy upvoted) - 使用Facebook的調試工具,它會告訴你它在找什麼 爲你的公共站點提供良好的元數據對於所有搜索引擎,搜索代理以及Facebook都有好處。 –