在requests headers中，我們可以看到If - Modified-Since 和If-None-Natch 這兩項，服務器就是通過檢查這兩項來判斷是否是已經做了緩存，因此在設置headers的時候只需要將這兩項刪除即可。
記抓取信息時遇到304狀態碼的應對方法
原創凍梨不是梨 最后發布於2018-08-30 13:21:08 閱讀數 1348 收藏
展開
在使用scrap有抓取 http://www.mzitu.com/ 時，無論是頁面解析還是相冊鏈接提取，都挺順利，但是在下載圖片的時候，卻總是返回304錯誤，導致圖片下載不下來
怎么辦呢？首先當然是百度了。百度 “python 爬蟲304錯誤” 然后點擊其中的一條，比如：
https://www.cnblogs.com/haitianzhimen/p/8549200.html 這一條。這里面詳細介紹了什么是304錯誤，以及如何產生的。懶癌症犯了，就直接復制粘貼了。
304狀態碼是什么?
如果客戶端發送了一個帶條件的GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個304狀態碼。簡單的表達就是：客戶端已經執行了GET，但文件未變化。
什么情況下會返回304狀態碼?
客戶端是怎么知道這些內容沒有更新的呢？其實這並不是客戶端的事情，而是你服務器的事情，大家都知道服務器可以設置緩存機制，這個功能是為了提高網站的訪問速度，當你發出一個GET請求的時候服務器會從緩存中調用你要訪問的內容，這個時候服務器就可以判斷這個頁面是不是更新過了，如果未更新過那么他會給你返回一個304狀態碼。
例如：一些搜索引擎是如何知道我們的網站是否有更新。判斷網頁是否發生變化最直接的方法是設置頁面的某一處為監控區域，每次都抓取該部分區域的內容，然后與本地保存的或最 近一次抓取內容比較，如果有差異就表明網頁發生了變化，才可以進行解析。這種方法比較穩妥，幾乎可達到萬無一失的效果。但是，這種方式在每次掃描時都要下載頁面內容，並且要去截取監控區域的內容，最后還要進行字符串比較，整個過程比較耗時。其實在眾多網頁中，有一部分網站的網頁內容是靜態頁面，如圖片，html，js等，這些靜態頁面往往可能是服務器早已准備好的，用戶訪問時僅僅是下載而已。那么針對這種靜態頁面，就可以僅僅通過304狀態碼來判斷，內容是否發生了變化。
如何解決?
如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭后的第一個空行結尾。
該響應必須包含以下的頭信息：
Date，除非這個服務器沒有時鍾。假如沒有時鍾的服務器也遵守這些規則，那么代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制將會正常工作。
ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。
Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。
假如本響應請求使用了強緩存驗證，那么本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。
假如某個304響應指明了當前某個實體沒有緩存，那么緩存系統必須忽視這個響應，並且重復發送不包含限制條件的請求。
假如接收到一個要求更新某個緩存條目的304響應，那么緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值
在進行條件請求時,客戶端會提供給服務器一個If-Modified-Since請求頭,其值為服務器上次返回的Last-Modified響應頭中的Date日期值,還會提供一個If-None-Match請求頭,值為服務器上次返回的ETag響應頭的值。
在進行條件請求時,客戶端會提供給服務器一個If-Modified-Since請求頭,其值為服務器上次返回的Last-Modified響應頭中的Date日期值,還會提供一個If-None-Match請求頭,值為服務器上次返回的ETag響應頭的值。
上面便是這篇博客的全部內容。 總而言之，一句話就是，服務器將要爬取的內容在本地做了緩存，再次請求的時候，會首先檢查本地是否有這個東西，如果有了就給你一個304，相當於告訴你：本地已經有了，我就不傳給你了啊。
那么他是怎么檢查的呢？
————————————————
版權聲明：本文為CSDN博主「凍梨不是梨」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_34246164/article/details/82219695