Вопрос по response, rest, json – Ответ сервера прерывается на полпути

35

У меня есть REST API, который возвращает ответы JSON. Иногда (и то, что кажется совершенно случайным), ответ json обрезается на полпути. Таким образом, возвращенная строка json выглядит так:

<code>...route_short_name":"135","route_long_name":"Secte // end of response
</code>

Я почти уверен, что это не проблема кодирования, поскольку точка отсечения постоянно меняет положение в зависимости от возвращаемой строки json. Я не нашел определенного размера ответа, для которого происходит отсечение (я видел, что 65 КБ не обрезаются, тогда как 40 КБ будут).

Посмотрим на заголовок ответа, когда обрезание действительно произойдет:

<code>{
    "Cache-Control" = "must-revalidate, private, max-age=0";
    Connection = "keep-alive";
    "Content-Type" = "application/json; charset=utf-8";
    Date = "Fri, 11 May 2012 19:58:36 GMT";
    Etag = "\"f36e55529c131f9c043b01e965e5f291\"";
    Server = "nginx/1.0.14";
    "Transfer-Encoding" = Identity;
    "X-Rack-Cache" = miss;
    "X-Runtime" = "0.739158";
    "X-UA-Compatible" = "IE=Edge,chrome=1";
}
</code>

Также не звонит. Кто-нибудь?

Ваш Ответ

7   ответов
32

У меня такая же проблема:

Nginx отключил некоторые ответы от FastCGI. Например, я не смог сгенерировать правильную резервную копию SQL из PhpMyAdmin. Я проверил логи и нашел это:

2012/10/15 02:28:14 [crit] 16443#0: *14534527 open() "/usr/local/nginx/fastcgi_temp/4/81/0000004814" failed (13: Permission denied) while reading upstream, client: *, server: , request: "POST / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "", referrer: "http://*/server_export.php?token=**"

Все, что мне нужно было сделать, чтобы это исправить, - это дать соответствующие разрешения/usr/local/nginx/fastcgi_temp папка, а такжеclient_body_temp.

Fixed!

большое спасибоsamvermetteВаш вопрос & amp; Ответ поставил меня на правильный путь.

Большое спасибо, сэкономьте мне много времени! Для моей настройки я попытался дать полный доступ к другой папке, и почему-то это не сработало, поэтому я решил ее, фактически переписав путь кproxy_buggering сохраняет файлыproxy_temp_path new/location/
Спасибо огромное!!! Я так долго дергал себя за волосы, пытаясь решить эту проблему, кто знал, что это будет так просто))
Этот ответ спасает меня! Но для 1.8 это было/var/cache/nginx/fastcgi_temp папка. Итак, я сделал командуchmod 777 /var/cache/nginx/ -R
Для CentOS мой / var / cache / nginx был root: владелец root! Так что мои "www-данные" пользователь не имел доступа :-( Также вы можете захотеть удалить ваши подкаталоги fastcgi_temp, потому что NginX предположительно сгенерирует их с правильными разрешениями.
9

У меня была похожая проблема с сокращением ответа от сервера.

Это случилось только когда я добавил заголовок json перед возвратом ответаheader('Content-type: application/json');

В моем случаеgzip вызвал проблему.

Я решил это, указавgzip_types вnginx.conf и добавлениеapplication/json перечислить перед включениемgzip:

gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;

gzip on;
Абсолютно спас мне жизнь с этим - спасибо!
У нас была такая же проблема, хотя конфигурация сервера была точно такой же, как в ответе. Добавление заголовка запроса «Принять кодировку: gzip»; на стороне клиента это решено.
это исправило это для меня и для установки Zend Expressive на Apache и Ubuntu 14 & amp; 16
0

У меня также была эта проблема & # x2013;JSON синтаксический анализ на стороне клиента был неисправен, ответ был обрезан или еще хуже, ответ был устаревшим и считывался из некоторого буфера произвольной памяти.

После просмотра некоторых руководств & # x2013;Обслуживание статического контента через POST от Nginx так же какNginx: исправить на & # x201C; 405 не разрешено & # x201D; при использовании POST выступающей статической при попытке настроить nginx для обслуживания простогоJSON файл.

В моем случае мне пришлось использовать:

max_ranges 0;

так что браузер не получает забавных идей, когда nginx добавляетAccept-Ranges: bytes в заголовке ответа)as well as

sendfile off;

в моемserver блок для прокси, который обслуживает статические файлы. Добавление его вlocation блок, который, наконец, будет служить найденнымJSON файл не помог.

Еще один прототип для подачи статикиJSONs также не забудет тип ответа:

charset_types application/json;
default_type application/json;
charset utf-8;

Другие поиски привели к проблемам с разрешением папки & # x2013;nginx обрезает конец динамических страниц и кэширует его или проблемы с буферизацией прокси-сервера & # x2013;Получение фрагментированного запроса через nginx, но это был не мой случай.

30

Посмотрел мой nginxerror.log файл и нашел следующее:

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

Похоже, что прокси-сервер nginx пытался сохранить содержимое ответа (переданное с помощью thin) в файл. Это происходит только тогда, когда размер ответа превышаетproxy_buffers (64 КБ по умолчанию на 64-битной платформе). Так что в итоге ошибкаwas связан с моим размером ответа на запрос.

Я закончил исправление своей проблемы, установивproxy_buffering вoff в моем конфигурационном файле nginx, вместо того, чтобы подниматьproxy_buffers или исправление проблемы с правами доступа к файлу.

Все еще не уверен насчет цели буфера nginx. Я был бы признателен, если бы кто-то мог добавить это. Является ли отключение буферизации полностью плохой идеей?

Я также использовал & quot; proxy_buffering off; & quot; что исправило мои проблемы. Не знаю другого способа сделать это лучше.
Большое спасибо, я попробовал, и это сработало для меня. Я читаю больше на эту тему, и, похоже, это не рекомендуемый способ.
Та же проблема. Спасибо, что спасли меня. Я был в своем уме & # x2019; конец здесь
2

Возможно, у вас закончились inode, что не позволяет NginX правильно использовать каталог fastcgi_temp.

Пытатьсяdf -i и если у вас 0% свободных инодов, это проблема.

Пытатьсяfind /tmp -mtime 10 (старше 10 дней), чтобы увидеть, что может заполнить ваш диск.

Или, может быть, это другой каталог со слишком большим количеством файлов. Например, перейдите на /home/www-data/example.com и сосчитайте файлы:

find . -print | wc -l

2

Спасибо за вопрос и отличные ответы, это сэкономило мне много времени. В конце концов, ответ Клемента и Сэма помог мне решить мою проблему, поэтому кредиты достаются им.

Просто хотел отметить, что после прочтения немного о теме, кажется, не рекомендуется отключатьproxy_buffering поскольку это может привести к зависанию вашего сервера, если, например, у клиентов (пользователей вашей системы) плохое интернет-соединение.

я нашелэто обсуждение очень полезно понять больше. Пример Фрэнсиса Дейли дал мне понять:

Perhaps it is easier to think of the full process as a chain of processes.

web browser talks to nginx, over a 1 MB/s link. nginx talks to upstream server, over a 100 MB/s link. upstream server returns 100 MB of content to nginx. nginx returns 100 MB of content to web browser.

With proxy_buffering on, nginx can hold the whole 100 MB, so the nginx-upstream connection can be closed after 1 s, and then nginx can spend 100 s sending the content to the web browser.

With proxy_buffering off, nginx can only take the content from upstream at the same rate that nginx can send it to the web browser.

The web browser doesn't care about the difference -- it still takes 100 s for it to get the whole content.

nginx doesn't care much about the difference -- it still takes 100 s to feed the content to the browser, but it does have to hold the connection to upstream open for an extra 99 s.

Upstream does care about the difference -- what could have taken it 1 s actually takes 100 s; and for the extra 99 s, that upstream server is not serving any other requests.

Usually: the nginx-upstream link is faster than the browser-nginx link; and upstream is more "heavyweight" than nginx; so it is prudent to let upstream finish processing as quickly as possible.

1

У нас была похожая проблема. Это было вызвано тем, что наш REST-сервер (DropWizard) включил SO_LINGER. Под нагрузкой DropWizard отключал NGINX, прежде чем он успел очистить его буферы. JSON был & gt; 8 КБ, и передний конец получал бы его усеченным.

Похожие вопросы