jQuery - Ошибка возврата Ajax 500 на некоторых сообщениях

Проверьте журналы ошибок apache и php ! он будет там

. Наиболее частой причиной этой проблемы является завершение работы сценария перед отправкой полного набора заголовков или, возможно, любого из них на сервер. Чтобы проверить, так ли это, попробуйте запустить сценарий автономно из интерактивного сеанса, а не как сценарий на сервере. Если вы получаете сообщения об ошибках, это почти наверняка причина сообщения «преждевременное завершение заголовков скрипта». Даже если CGI нормально работает из командной строки, помните, что среда и разрешения могут отличаться при работе на веб-сервере.CGI может получить доступ только к ресурсам, разрешенным для пользователя и группы, указанных в вашей конфигурации Apache. Кроме того, среда не будет такой же, как в командной строке, но ее можно настроить с помощью директив, предоставляемых mod_env.

Вторая наиболее частая причина этого (не считая того, что люди вообще не выводят требуемые заголовки) - это результат взаимодействия с буферизацией вывода Perl. Чтобы Perl очищал свои буферы после каждого оператора вывода, вставьте следующие операторы вокруг операторов печати или записи, которые отправляют ваши HTTP-заголовки:

{
    local ($oldbar) = $|;
    $cfh = select (STDOUT);
    $| = 1;
    #
    # print your HTTP headers here
    #
    $| = $oldbar;
    select ($cfh);
}

Это обычно необходимо только тогда, когда вы вызываете внешние программы из вашего сценария, которые отправляют вывод на stdout, или если будет большая задержка между отправкой заголовков и началом передачи фактического содержимого. Чтобы максимизировать производительность, вы должны отключить очистку буфера (с $ | = 0 или эквивалентным) после операторов, отправляющих заголовки, как показано выше.

Если ваш сценарий написан не на Perl, сделайте то же самое для любого языка, который вы используете (например, для C вызовите fflush () после записи заголовков).

Другой причиной сообщения «преждевременный конец заголовков сценария» являются директивы RLimitCPU и RLimitMEM. Вы можете получить сообщение, если сценарий CGI был убит из-за ограничения ресурсов.

Кроме того, проблема конфигурации в suEXEC, mod_perl или другом стороннем модуле часто может мешать выполнению вашего CGI и вызывать сообщение «преждевременный конец заголовков скрипта».

CPHP:

• http: //cakebaker.42dh.com / 2007/07/18 / premature-end-of-script-headers-with-baked-views /

Вы можете использовать Fidler , чтобы проверить, что сервер вернул во время этого $ .post. Он будет содержать веб-страницу, которая была бы возвращена, если бы вы запустили тот же метод непосредственно в своем браузере.

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

Что делает ваша страница...? Вот некоторые предположения.

Если ваша страница похожа на страницу автозаполнения, то есть вы передаете немного информации и получаете отфильтрованный список результатов... Возможно, ваш AJAX-скрипт не передает обратно элемент данных, и ваша страница пытается вернуть все. Очень громоздкие PHP-скрипты (т.е. интенсивные/рекурсивные операции) могут вызвать эту ошибку.

Обычный совет по устранению этой конкретной ошибки заключается в том, чтобы вернуться к стабильной странице и затем начать добавлять материал обратно - так что, возможно, направьте ваш AJAX-скрипт на страницу, на которой есть это...

<?php
    echo 'If this appears, we\'re stable!';
?>

Затем постепенно добавляйте блоки вашего кода, пока не столкнетесь с проблемой. Я бы предложил версию 2 этой страницы...

<?php
    print_r($_POST);
?>

Так как это позволит вам проверить, что возвращается в форме сообщения.

Если все вышеперечисленное не работает, пожалуйста, предоставьте следующее...

1) Описание того, что делает ваша PHP-страница, или, возможно, пример кода. 2) Код JavaScript, который вызывает PHP-страницу.

Возможно, производственный сайт нарушает политику одинакового происхождения.

URL в браузере до третьего слэша должен точно совпадать с URL в вашем AJAX POST, иначе ограничения безопасности браузера для Javascript отклонят ответ. Сервер может увидеть запрос и ответить правильно, но браузер передаст пустую строку обратно вызову AJAX.

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

В общем, это ошибка PHP, и мы можем исключить проблемы на стороне клиента. Вдобавок ко всему, в моей повседневной работе (устранение неполадок в сети), если что-то работает, а затем останавливается, я сразу думаю, «что изменилось». Если вы ничего не добавляли к сценарию и у пользователя нет возможности повлиять на сценарий во время выполнения, я бы сразу начал думать: «Ой, что с инфраструктурой». Это особенно верно, если что-то работает локально, но не через Интернет.

Проверяли ли вы наличие плохой памяти на сервере или плохих сетевых адаптеров (если они плохие, это объясняет, почему один интерфейс работает, а другой нет). У вас есть к нему доступ или он размещен (может ли ваш хост проверять)?

Затем я бы начал думать, хорошо, с памятью сервера все в порядке, и это вряд ли связано с неисправным сетевым адаптером, иначе он будет периодически выходить из строя и в разных местах. Хотя все еще может быть нетворкинг. Есть ли устройство безопасности, которое может искажать пакеты в любом месте микса (NIDS / HIDS, WAF, прокси и т. Д.?). Вы видите какие-либо сетевые проблемы с пакетами (дубликаты, не в порядке, не фрагментировать и т. Д.).

Я буду честен, если бы кто-то позвонил мне на стол и описал мне ваши проблемы, первое, что я бы сказал, это «проверьте журналы IPS», примерно 85% это проблема.Ложные срабатывания могут сделать это, и все, что нужно, - это одно автоматическое обновление брандмауэра ...

Я надеюсь, что это поможет.