Safari тихо переводит 200 ответов на AJAX-запросы в 304 - PullRequest
Новая
       21

Safari тихо переводит 200 ответов на AJAX-запросы в 304

5 голосов
/ 17 декабря 2011

РЕЗЮМЕ: Safari сообщает 304 ответа, хотя он получает 200 на запросы XHR

Здравствуйте. У меня странная ситуация с Safari, и я уже в конце пути, пытаясь исследовать его самостоятельно, надеюсь, кто-то здесь сталкивался с этим в прошлом.

В настоящее время я начал использовать свое приложение (толстый клиент Sencha Touch, взаимодействующий с RESTful API, обслуживаемым NodeJS) в Safari и заметил, что браузер иногда (на самом деле: примерно 5 раз из 6) неправильно обрабатывает ответы сервера, и сообщать о них (в сетевой консоли инструментов разработчика) как 304 ответа без содержимого вместо 200 ответов с содержимым JSON, которые фактически доставляются. (И приложение ведет себя соответственно - ответы без содержания 304 заставляют приложение предполагать, что у него нет данных, и оно отвечает таким образом, так что это не просто косметическая проблема на панели разработчика.)

Заголовки даже не верны - вот непересекающийся набор заголовков Response, сообщенных Safari для двух случаев (я подтвердил, что содержимое request и заголовки идентичны для двух):

200

  • Access-Control-Allow-Credentials: правда
  • Access-Control-Allow-Headers: *
  • Access-Control-Allow-метода: GET, POST, UPDATE, DELETE, OPTIONS
  • Access-Control-Allow-Origin: не определено
  • Content-Type: применение / JSON; кодировка = UTF-8

304

  • Content-Type: текст / JavaScript
  • Дата последнего изменения: вс, 20 ноября 2011 г. 22:30:45 GMT
  • Сервер: lightnode
  • Transfer-Encoding: Идентичность

(я опустил заголовки ответа, которые идентичны между ними.)

Несколько других заметок

  • Я проверил, что ответы, отправленные сервером, идентичны на каждый запрос, и tcpdump'ed трафик, и подтвердил, что сервер отправляет 200 кодов ответов (и заголовков), которые затем сообщаются и обрабатываются Safari. поскольку 304 ответа не содержат содержимого (и с поддельными заголовками выше.) Safari сообщает об ответе, который никогда не отправлялся.
  • Вышеприведенные заголовки 304 выглядят аналогично тому, что может быть отправлено вместе со статическим содержимым в этом приложении, но я подтвердил, что оба ответа обслуживаются одним и тем же путем кода (сервер API, т. Е. Не задействован «легкий узел», эти заголовки создаются Safari.)
  • Я никогда не вижу такого поведения в Chrome
  • Я подтвердил ту же ошибку поведения приложения в Mobile Safari (для которого построен Sencha Touch, наряду со всеми другими браузерами WebKit, такими как Safari и Chrome), но не смог подтвердить фиктивная обработка ответов, поскольку iOS на самом деле не предоставляет эту низкоуровневую отладочную информацию.
  • Здесь нет проблем с XSS / CORS, API и статический контент обслуживаются из одного домена.
  • Да, я сделал все обычные операции инициализации cookie / cache / restart / etc, безрезультатно.

Версия

  • Safari: 5.1.1
  • OSX: 10.7.2

1 Ответ

0 голосов
/ 24 марта 2014

Отличная исследовательская работа. То, что вы видите, - это перенаправление Ajax, и обычно вы не можете видеть его в большинстве инструментов разработчика, но, тем не менее, это происходит. В идеале это не должно влиять на ваше приложение, в вашем вопросе я не вижу, чтобы вы сообщали о каких-либо проблемах или ошибках, просто больше запросов.

Это перенаправление обрабатывается на уровне браузера, поэтому вы ничего не можете с этим поделать (я пытался в прошлом и ничего не мог с этим поделать).

Между прочим, это не проблема sencha, а то, как Ajax ведет себя.

Надеюсь, это поможет

...