Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.17.186.140] |
|
Сообщ.
#1
,
|
|
|
Всем привет.. Сталкиваюсь с проблемой, уже не знаю куда копать. Попробую описать суть происходящего.
Сборка на Ubuntu / Nginx / php-fpm Страница посылает Ajax запрос скрипту $.post("/pages/servicedesk_sync.php", {showdata: "yes"}) .done(function(data) { $("#content2").html(data); }); Однако при запросе AJAX Консоль браузера ругается на 404. С директорией к скрипту все точно нормально ниже опишу почему. jquery.min.js:4 POST https://xxxxxxxx.ru/pages/servicedesk_sync.php 404 (Not Found) send @ jquery.min.js:4 ajax @ jquery.min.js:4 n.(anonymous function) @ jquery.min.js:4 (anonymous) @ index.php?&page=servicedesk:528 j @ jquery.min.js:2 fireWith @ jquery.min.js:2 ready @ jquery.min.js:2 I @ jquery.min.js:2 Сам Скрипт "/pages/servicedesk_sync.php" отрабатывает великолепно и выдает довольно большой и обьемный текст почти 20к строк. Во первых я записывал вывод скрипта в текстовый файл потом его проверял.Во вторых я открывал его в браузере по прямой ссылке подставив ему GET параметры (и обработав их вместо POST) и он выдает весь текст. Но вот какую закономерность я заметил!! если попытаться ограничить вывод этого скрипта, скажем сократить его подставив exit; где нибудь в середине то Ajax запрос его великолепно отрабатывает и выводит. отсюда в голове мысль что Ajax упирается в какой -то потолок то ли размера вывода, то ли выделенной памяти, то ли размера текста, при этом в Nginx -> error.log появляется запись [error] 4938#0: *2 upstream prematurely closed FastCGI stdout while reading response header from upstream Погуглил, перепробовал разные параметры из серии fastcgi_buffers 256 256k; / fastcgi_buffer_size 256k; -перепробовал разные вариации ничего не помогло... Помогите понять в чем причина и что еще можно предпринять? Конфиг server { listen 443 ssl; listen [::]:443 default_server ipv6only=on; # root /var/www; index index.php index.html index.htm; server_name xxxxxxx.ru; ssl on; ssl_certificate /var/ssl/xxxxxxx.crt; ssl_certificate_key /var/ssl/xxxxxxxx.key; location / { try_files $uri $uri/ =404; #proxy_request_buffering off; } error_log /var/log/nginx/error2.log error; access_log off; error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_connect_timeout 15s; fastcgi_read_timeout 1600; fastcgi_send_timeout 1600; fastcgi_buffers 256 256k; fastcgi_buffer_size 256k; fastcgi_temp_file_write_size 512k; fastcgi_busy_buffers_size 256k; client_max_body_size 200m; reset_timedout_connection on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/:/usr/share/:/tmp/"; include fastcgi_params; client_body_temp_path /var/www/client_body_temp; proxy_temp_path /var/www/proxy_temp; proxy_buffering off; fastcgi_temp_path /var/www/temp; } |
Сообщ.
#2
,
|
|
|
Странная проблема. AJAX ничем вообще не отличается от обычных запросов. Возможно там внутри кода (т.е. самого скрипта) стоит соответствующая логика, которая и отдаёт этот самый 404
Ну вроде if (($_SERVER['X-Requested-With'] ?? null) === 'XMLHttpRequest') { \header('HTTP/1.0 404 Not Found'); } |
Сообщ.
#3
,
|
|
|
Цитата Serafim @ Странная проблема. AJAX ничем вообще не отличается от обычных запросов. Возможно там внутри кода (т.е. самого скрипта) стоит соответствующая логика, которая и отдаёт этот самый 404 Ну вроде if (($_SERVER['X-Requested-With'] ?? null) === 'XMLHttpRequest') { \header('HTTP/1.0 404 Not Found'); } нет такой логики там нет, скрипт то я тоже сам писал и более того напрямую он открывается нормально.. Я понимаю что ajax такой же по сути запрос, вот и пытаюсь понять где же может быть проблема. Однако проблема наблюдается подчеркну, только при большой выдаче. Стоит уменьшить выдачу (например уменьшить количество выводимых данных путем выставления лимита в запросе в базу) и проблема пропадает. |
Сообщ.
#4
,
|
|
|
не нашел ответа на свой вопрос( переделал в итоге логику раздробил на более мелкие запросы...(
|
Сообщ.
#5
,
|
|
|
Цитата secondvad2 @ переделал в итоге логику раздробил на более мелкие запросы...( Так и нужно было делать изначально. Не стоит гонять по http запросы больше сотни килобайт. Вполне возможно соединение отваливается просто. Хотя там не 404 должно быть, очевидно, а 504 (если на сервере) и без кода, если на клиенте. С другой стороны, в 2018ом году и JQuery никто не использует, т.к. проще написать: await fetch('/pages/servicedesk_sync.php', {body: {showdata: 'yes'}}); Ну и отдельные php файлики, вместо общего - тоже плохо. Добавлено P.S. Ну и для сервера стоит добавить dhparam и hsts, перечислить ciphers и протоколы но это вообще оффтоп. Скрытый текст Конфиг одного из моих сайтиков для сертификата А+ ssl on; ssl_session_timeout 24h; ssl_certificate .../fullchain.pem; ssl_certificate_key .../key.pem; ssl_dhparam .../dhparam.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS; # AES 128, кстати, слабый, можно исключить уже. ssl_session_cache shared:SSL:10m; ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'; add_header X-Frame-Options 'DENY'; add_header X-XSS-Protection '1; mode=block'; |
Сообщ.
#6
,
|
|
|
fastcgi_busy_buffers_size 256k; |