Правильный способ обработки 304 не изменен в jQuery ajax

Как и в jQuery 1.5, методы ajax теперь корректно обрабатывают 304 Not Modified ответы, вызывая обработчик success(), согласно спецификации W3C для XMLHTTPRequest. Это позволяет вашему приложению обрабатывать запрос как успешный, даже если сервер фактически не возвратил данные (поскольку у вас уже есть последние данные, кэшированные).

Для обычного (неэкранированного) запроса GET обработчик успеха вызывается со следующими аргументами:

данные: {данные с сервера}
статус: ОК
jqXHR:
- статус: 200
- statusText: OK
- responseText: {данные с сервера}

Для кэшированного запроса GET обработчик успеха вызывается со следующими аргументами:

данные: undefined
статус: notmodified
jqXHR:
- статус: 304
- statusText: notmodified
- responseText: {данные из кэша}

(по крайней мере, так оно возвращается в IOS 4.2 для веб-приложения, использующего кеш приложения через файл манифеста. Я предполагаю, что это совместимо для общего кеширования браузеров на большинстве платформ/браузеров).

Вы можете видеть, что аргумент "data" заполняется только в том случае, если запрос был 200 OK; где, поскольку 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, который всегда возвращал данные, даже из кеша); поэтому я просто хочу убедиться, что я правильно это обработаю. (Не пытайтесь дойти до конца, а затем осознайте, что я должен был сделать это по-другому).

Ответ 1

Я только заметил явный недостаток в своем вопросе.... Я предполагал, что данные всегда были текстовыми, поэтому использование jqXHR.responseText в предпочтении аргумента данных имеет смысл.

Но в том случае, если dataType является JSON, JSONP, script и т.д.... если данные, возвращенные в ответе 304 Not Modified, возвращаются как undefined, вам нужно будет преобразовать jqXHR.responseText из сначала введите нужный тип, например.

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

... и вы бы хотели сделать это (потенциально дорогое) преобразование, когда вам действительно нужно.

Теперь у меня есть смысл понять, что я думаю об этом... данными всегда будет то, что вернулось с сервера (что в некоторых случаях может не быть undefined для 304... например, сервер может вернуться некоторый дополнительный текст /html ); что позволяет разработчику гибко выбирать, что они хотят делать в случае 304, например.

Отобразить ответ с сервера (если есть)
Используйте jqXHR.responseText
Сделайте что-то еще полностью...

Ответ 2

В зависимости от контекста вы можете использовать параметр cache для запроса ajax:

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

Это работает для меня.