在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