为什么JavaScript的fetch()不需要检查状态码304? [英] Why does JavaScript's fetch() not need to check for status code 304?

查看:100
本文介绍了为什么JavaScript的fetch()不需要检查状态码304?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

用于显示如何正确使用 fetch()甚至处理被认为不是错误的 404 500 的代码是检查 response.ok :

The code to show how to use fetch() properly, even to handle 404 or 500 which is considered not an error, is to check for response.ok:

fetch("   ")
  .then(response => {
    if (response.ok) return response.json();
    else throw new TypeError("No fetch data");
  })
  .then(d => setData(d))
  .catch(err => { handleError(err); });

或检查 response.status ,但目标是检查状态码是否在200到299(包括)之间,这是 response.ok 可以执行的操作.

or to check for response.status, but the goal is to check for status code being in the range of 200 to 299, inclusive, which is what response.ok can do.

但是,如果状态代码为 304 ,则表示数据未更改,为什么不需要处理这种情况?我确实记得在jQuery时代,也总是检查代码 304 ,这意味着它是有效的数据形式.在 https://code.jquery.com/jquery-3.6.0.js

However, if the status code is 304, which means data has not changed, why does this case not need to be handled? I do remember in the days of jQuery, the code 304 is always checked for as well, which means it is a valid form of data. On https://code.jquery.com/jquery-3.6.0.js

isSuccess = status >= 200 && status < 300 || status === 304;

我只能在看到有关 fetch的规范()

如果响应为空,则:...如果设置了revalidatingFlag且forwardResponse的状态为304,则:...将响应设置为storedResponse.

If response is null, then: ... If the revalidatingFlag is set and forwardResponse’s status is 304, then: ... Set response to storedResponse.

因此,似乎响应已设置为缓存版本,但我看不到提及将 304 更改为 200 的事情.

So it looks like the response is set to the cached version, but I don't see the mentioning of changing the 304 to 200.

为什么在 fetch()的情况下不需要考虑 304 的情况?

Why does we not need to consider the case for 304 in the case of fetch()?

推荐答案

您正在执行http-fetch 请求,该请求在第3步输入

You are doing an http-fetch request, which at step 3 enters the http-network-or-cache-fetch algorithm, which itself would enter the step 8.23 because the request is probably already in your cache.

  1. 将响应设置为 storedResponse .

然后,该算法将启动一个新的 revalidateRequest 以并行方式重新验证缓存,该缓存的响应状态设置为304,但是返回的一个响应实际上是缓存的一个,而不是304个响应.

Then the algorithm will start a new revalidateRequest to revalidate the cache in parallel, which will have its response's status set to 304, but the one response that is being returned is actually the cached one, not that 304 response.

如规格说明中所述:

此访存仅旨在更新httpCache 的状态,并且该响应将不被使用,直到进行另一次缓存访问为止.过时的响应将用作对当前请求的响应.

返回的 storedResponse 可能不是304响应,而且肯定不是null正文响应,因此您无需检查它.

The storedResponse that is being returned was probably not a 304 response, and certainly not a null body response, so you don't need to check for it.

如果服务器确实返回了带有空主体的304响应,则您将陷入步骤10中,该响应将返回NetworkError.

If the server did return a 304 response with null body, then you'd fall in the step 10 which would return a NetworkError.

这是一个小故障设置,以某种方式显示了这一点.

Here is a glitch setup showing this, somehow.

这篇关于为什么JavaScript的fetch()不需要检查状态码304?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆