jQuery Ajax-вызовы в нашем приложении не работают, когда я открываю инструменты разработчика для отслеживания вызовов API. Получение 500 внутренней ошибки.
Если я закрою окно инструмента разработчика, оно будет работать нормально.
Это происходит на производственном сервере. На моем локальном сервере он работает нормально в обоих направлениях.
Я попытался запустить профилировщик java для записи в хроме, он работает. Как только я перестаю, он не работает.
Когда я читаю журналы сервера, он пытается проверить токен CSRF, где токен не соответствует. Это выбрасывает исключение. Но все же путаница в том, почему эта ошибка возникает только при открытии окна отладки.
Мой код вызова Ajax выглядит следующим образом:
jQuery.ax=function(url, data, async, type, dataType, successfn, errorfn) {
async = (async==null || async= = "" || typeof(async)= = "undefined")? "true" : async;
type = (type==null || type= = "" || typeof(type)= = "undefined")? "post" : type;
dataType = (dataType==null || dataType= = "" || typeof(dataType)= = "undefined")? "json" : dataType;
data = (data==null || data= = "" || typeof(data)= = "undefined")? {"date": new Date().getTime()} : data;
data.avoidCacheDate = new Date().getTime();
data.AJAXREQUEST = true;
$.ajax({
type: type,
beforeSend: function (request){
getToken(request);
},
async: async,
data: data,
url: url,
dataType: dataType,
success: function(d){
successfn(d);
},
error: function(e){
errorfn(e);
}
});
};
Производственный сервер означает журналы промежуточного программного обеспечения, которые вы запрашиваете.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


может это проблема кеширования? Ваш ответ 200 (хороший) может быть просто кэширован (вы не установили опцию cache: false в вашем примере кода, по умолчанию это true). В Chrome DevTools есть флажок «Отключить кеш» на вкладке «Сеть». Итак, когда вы открываете DevTools, ваши запросы действительно отправляются на сервер (и получают свежий / фактический / реальный ответ 500).
Просто добавьте cache: false, чтобы избежать кеширования, и вы, вероятно, всегда получите 500, пока не устраните проблему.
PS: использование поля данных avoidCacheDate в качестве средства блокировки кеша неверно, так как data будет передан в строку запроса только в случае запроса «GET». Для других (например, POST или PUT) он перейдет к полезной нагрузке запроса. Для этого используйте опцию cache.
Привет Roman86, Спасибо за ответ. Подводя итог, если я установил для кеша значение false в запросе ajax, он всегда будет выдавать ошибку 500, пока мы не исправим проблему. Но если я закрою окно инструментов разработчика, мой API вернет мне данные. Я новичок в разработке, где добавление кеша в false к запросу для производственного приложения будет хорошей идеей?
привет @ user3093856! в большинстве случаев использование cache: false является правильным способом, особенно когда вы запрашиваете какую-либо конечную точку API и ожидаете свежих данных при каждом запросе. Кеширование может быть полезно для некоторых статических ресурсов, которые редко меняются и не влияют на работу приложения. По поводу закрытых DevTools ошибок нет - странно. Если выставили cache: false - всегда должен быть свежий ответ (500?). Попробуйте выполнить свой запрос в ARC. Или (если он GET) просто откройте его в новой вкладке, добавив случайный параметр в URL-адрес
Роман, я добавил cache: false, заголовки: {"Cache-Control": "no-cache", "Pragma": "No-cache"}, но все такое же поведение. не понимая, в чем будет проблема.
@ user3093856 давайте проясним - он все равно возвращает 200, если DevTools не активен? А 500 только с DevTools?
@ user3093856 это запрос GET, PUT или POST? Вы пробовали выполнить его вне браузера? Как ARC или Curl
Вне браузера запрос работать не будет. Безопасность CSRF включена.
Токен CSRF - это просто заголовок. Вы также можете смоделировать это вне браузера: youtube.com/watch?v=a4xM5PbVNv0
Спасибо Роману за поддержку. Когда я делаю запрос от внешне работающего нормально. Думая, что CSRF берет СТАРЫЙ токен-код. Но я добавил cache false и async: false. Но не знаю почему до сих пор размножаюсь.
С нашей стороны, невозможно сказать почему. Так в чем же ошибка на рабочем сервере? Вы смотрели журналы?