python爬蟲遇到狀態代碼304,705，python304

python爬蟲遇到狀態代碼304,705，python304
304狀態代碼是什麼?

 　　如果用戶端發送了一個帶條件的GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個304狀態代碼。簡單的表達就是：用戶端已經執行了GET，但檔案未變化。

 

什麼情況下會返回304狀態代碼?　　用戶端是怎麼知道這些內容沒有更新的呢？其實這並不是用戶端的事情，而是你伺服器的事情，大家都知道伺服器可以設定緩衝機制，這個功能是為了提高網站的訪問速度，當你發出一個GET請求的時候伺服器會從緩衝中調用你要訪問的內容，這個時候伺服器就可以判斷這個頁面是不是更新過了，如果未更新過那麼他會給你返回一個304狀態代碼。 　　例如：一些搜尋引擎是如何知道我們的網站是否有更新。判斷網頁是否發生變化最直接的方法是設定頁面的某一處為監控地區，每次都抓取該部分地區的內容，然後與本地儲存的或最 近一次抓取內容比較，如果有差異就表明網頁發生了變化，才可以進行解析。這種方法比較穩妥，幾乎可達到萬無一失的效果。但是，這種方式在每次掃描時都要下載頁面內容，並且要去截取監控地區的內容，最後還要進行字串比較，整個過程比較耗時。其實在眾多網頁中，有一部分網站的網頁內容是靜態頁面，片，html，js等，這些靜態頁面往往可能是伺服器早已準備好的，使用者訪問時僅僅是下載而已。那麼針對這種靜態頁面，就可以僅僅通過304狀態代碼來判斷，內容是否發生了變化。 如何解決?　　如果用戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個狀態代碼。304響應禁止包含訊息體，因此始終以訊息頭後的第一個空行結尾。 　　　　該響應必須包含以下的頭資訊： 　　　　Date，除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則，那麼Proxy 伺服器以及用戶端可以自行將 Date 欄位添加到接收到的回應標頭中去（正如RFC 2068中規定的一樣），緩衝機制將會正常工作。 　　　　ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。 　　　　Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。 　　 　　假如本響應請求使用了強緩衝驗證，那麼本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩衝驗證），本次響應禁止包含其他實體頭；這避免了緩衝了的實體內容和更新了的實體頭資訊之間的不一致。 　　　　假如某個304響應指明了當前某個實體沒有緩衝，那麼緩衝系統必須忽視這個響應，並且重複發送不包含限制條件的請求。 　　　　假如接收到一個要求更新某個緩衝條目的304響應，那麼緩衝系統必須更新整個條目以反映所有在響應中被更新的欄位的值  　　在進行條件請求時,用戶端會提供給伺服器一個If-Modified-Since要求標頭,其值為伺服器上次返回的Last-Modified回應標頭中的Date日期值,還會提供一個If-None-Match要求標頭,值為伺服器上次返回的ETag回應標頭的值。 　　當網站的狀態代碼是304的時候 ，爬蟲或返回705的狀態資訊。說明WAP網關與遠端伺服器建立串連失敗。 　　參考狀態代碼資訊：　　http://tool.oschina.net/commons?type=5　　https://wenku.baidu.com/view/4e06018483d049649b66581c.html