你最好弄清楚這樣的屏幕抓取問題是使用Fiddler。使用Fiddler,您可以準確比較應用程序中的線路與從瀏覽器訪問網站時的情況。我懷疑你會看到你的應用程序發送的頭文件與瀏覽器發送的頭文件有一些區別 - 這可能會解釋你所看到的差異。
接下來,你可以做兩件事情之一:
- 改變你的應用程序發送準確的報頭,瀏覽器不會(如果你這樣做,你應該得到確切的答覆中說一個真正的瀏覽器獲得)。
- 使用Fiddler的「請求生成器」功能,開始逐個刪除標頭並重新發出請求。在某個時候,你會刪除一個標題,使得響應與你正在尋找的響應不匹配。這意味着頭是必需的。繼續所有其他標題,直到您有一個網站所需的標題列表,以產生您想要的響應。
就個人而言,我喜歡選項#2,因爲它需要最少量的頭文件設置代碼,儘管最初很難確定網站需要哪些頭文件。
在您爲什麼看到2個Cookie的實際問題中,只有上述診斷肯定會告訴您,但我懷疑它可能與某些網站用於檢測不接受客戶的機制有關餅乾。在會話的第一個請求中,許多站點將「探測」客戶端以查看客戶端是否接受cookie。通常他們會這樣做:
- 如果請求沒有cookie,網站會將客戶端重定向到一個特殊的「cookie設置」URL。
- 重定向響應除了具有重定向的Location:標頭之外,還將返回Set-Cookie標頭來設置Cookie。重定向通常將包含原始URL作爲查詢字符串參數。
- 「cookie setter」頁面的服務器端處理程序將查看傳入的cookie。如果它是空白的,這意味着用戶的瀏覽器被設置爲不接受cookie,並且該網站通常會將用戶重定向到「對不起,您必須使用cookie來使用本網站」頁面。
- 但是,如果有一個cookie頭髮送到「cookie setter」URL,那麼客戶端實際上會接受cookie,處理程序將簡單地將客戶端重定向回原始URL。
- 原始URL在您轉到下一頁時,可能會添加一個附加的Cookie(例如,用於登錄令牌)。
無論如何,這是一種方式,你可以結束了兩個餅乾。不過,只有使用Fiddler(或類似的工具)進行診斷才能確定。
你的問題很難弄清楚。這些cookies顯然來自itpub.net。你問他們爲什麼發送? – zombat 2009-12-26 23:34:36
你能代碼嗎?你在做什麼語言? – 2009-12-26 23:56:18
請發佈確切的代碼,您使用http請求 – 2009-12-27 00:07:44