处理 jQuery ajax 中未修改的 304 的正确方法

发布于 2024-10-20 14:44:50 字数 1215 浏览 1 评论 0原文

从 jQuery 1.5 开始,ajax 方法现在可以根据 XMLHTTPRequest 的 W3C 规范,通过调用 success() 处理程序来正确处理 304 Not Modified 响应。这允许您的应用程序将请求视为成功,即使服务器实际上没有返回任何数据(因为您已经缓存了最新的数据)。

对于正常(未缓存)的 GET 请求,将使用以下参数调用成功处理程序:

  • data: { 来自服务器的数据 }
  • status: OK
  • jqXHR:
    • 状态:200
    • 状态文本:确定
    • responseText:{来自服务器的数据}

对于缓存的 GET 请求,使用以下参数调用成功处理程序:

  • data: undefined
  • status: notmodified
  • jqXHR:
    • 状态:304
    • statusText:未修改
    • responseText: { 缓存中的数据 }

(至少,对于通过清单文件使用应用程序缓存的网络应用程序来说,这是在 IOS 4.2 中返回的方式。我'我假设这对于大多数平台/浏览器上的一般浏览器缓存是一致的)。

您可以看到,仅当请求为 200 OK 时才会填充“data”参数;其中 jqXHR.responseText 始终填充有数据,无论该数据是来自服务器(200 OK)还是来自缓存(304 Not Modified)。

鉴于在大多数 GET 请求中,您的成功处理程序都希望对您获得的数据执行某些操作,无论数据来自何处,对于您的成功代码而言,始终使用 jqXHR.responseText 似乎是最有意义的,而不是做这样的事情:

if ("notmodified" === status) {
  // do something with jqXHR.responseText
} else {
  // do something with data
}

或者是否存在 jqXHR.responseText 不会填充在成功处理程序中,但数据参数的情况?

我必须检查我的代码库并更改所有成功处理程序(以前我使用的是 jQuery 1.4.2,它总是返回数据,甚至从缓存中返回数据);所以我只是想确保我以正确的方式处理它。 (不想读到最后然后意识到我应该以另一种方式做到这一点)。

As of jQuery 1.5, the ajax methods now correctly handle 304 Not Modified responses by calling the success() handler, as per the W3C spec for XMLHTTPRequest. This allows your application to treat the request as being successful, even if the server didn't actually return any data (because you already have the latest data cached).

For a normal (uncached) GET request, the success handler is called with the following args:

  • data: { the data from the server }
  • status: OK
  • jqXHR:
    • status: 200
    • statusText: OK
    • responseText: { the data from the server }

For a cached GET request, the success handler is called with the following args:

  • data: undefined
  • status: notmodified
  • jqXHR:
    • status: 304
    • statusText: notmodified
    • responseText: { the data from the cache }

(at least, this is how it is returned in IOS 4.2, for a web-app that uses the application cache via a manifest file. I'm assuming this is consistent for general browser caching on most platforms/browsers).

You can see that the "data" argument is only populated if the request was 200 OK; where as the jqXHR.responseText is always populated with data, regardless of whether that data came from the server (200 OK) or from the cache (304 Not Modified).

Given that, in most GET requests, your success handler is going to want to do something with the data you got regardless of where it came from, it would seem to make the most sense for your success code to always use the jqXHR.responseText, rather than doing something like this:

if ("notmodified" === status) {
  // do something with jqXHR.responseText
} else {
  // do something with data
}

Or is there ever a case when jqXHR.responseText wouldn't be populated in the success handler, but the data arg would?

I have to go through my codebase and change all success handlers (previously I was on jQuery 1.4.2, which always returned data, even from the cache); so I just want to make sure I'm handling it the right way. (Don't wan't to get to the end and then realise I should have done it another way).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不知在何时 2024-10-27 14:44:50

我刚刚发现了我的问题中明显的缺陷......我假设数据始终是文本,因此使用 jqXHR.responseText 优先于数据参数是有意义的。

但在 dataType 为 JSON、JSONP、脚本等的情况下...如果 304 Not Modified 响应中返回的数据返回为未定义,则需要首先将 jqXHR.responseText 从字符串转换为所需的类型,例如。

if (data === undefined) {
  data = $.parseJSON(jqXHR.responseText);
}

...并且您只想在真正需要时进行此(可能昂贵的)转换。

现在我想起来有点有道理...数据总是从服务器返回的数据(在某些情况下对于 304 可能不是未定义...例如服务器可以返回一些额外的文本/html);这使得开发人员能够灵活地选择在发生 304 事件时他们想要做什么,例如。

  • 显示来自服务器的响应(如果有)
  • 使用 jqXHR.responseText
  • 完全做其他事情...

I've just spotted the obvious flaw in my question....I was assuming that the data was always text, so using jqXHR.responseText in preference to the data argument made sense.

But in the case that the dataType is JSON, JSONP, script etc...if the data returned in a 304 Not Modified response comes back as undefined, you'd need to convert the jqXHR.responseText from a string to the desired type first, eg.

if (data === undefined) {
  data = $.parseJSON(jqXHR.responseText);
}

...and you'd only want to do this (potentially expensive) conversion when you need really to.

Kinda makes sense now that I think about it...data is always going to be what came back from the server (which in some cases might not be undefined for a 304...eg. the server could return some additional text/html); which allows the developer the flexibility to choose what they want to do in the event of a 304, eg.

  • Display the response from the server (if any)
  • Use the jqXHR.responseText
  • Do something else entirely...
半夏半凉 2024-10-27 14:44:50

根据上下文,您可以在 ajax 请求中使用 cache 参数:

$.ajax({
    url: ".....",
    dataType: "json",
    type: "GET",
        cache: false,
    contentType: "application/json",
        success: function (data, textStatus) {
            console.log("RECV: " + data);
        }
    });

这对我有用。

Depending on context, you could use the cache parameter to the ajax request:

$.ajax({
    url: ".....",
    dataType: "json",
    type: "GET",
        cache: false,
    contentType: "application/json",
        success: function (data, textStatus) {
            console.log("RECV: " + data);
        }
    });

That's working for me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文