Serverantwort wird auf halbem Weg abgeschnitten

Question

Ich habe eine REST-API, die JSON-Antworten zurückgibt. Manchmal (und was scheinbar völlig zufällig ist) wird die JSON-Antwort auf halbem Weg abgeschnitten. Deshalb ist die zurück JSON-String wie folgt aussieht:

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

Ich bin ziemlich sicher, es ist nicht eine Codierung Problem, weil die Grenzpunktlage ändert sich ständig in Abhängigkeit von der json Zeichenfolge, die zurückgegeben wird. Ich habe auch keine bestimmte Antwortgröße gefunden, für die der Cut-Off-Effekt eintritt (ich habe gesehen, dass 65kb nicht abgeschnitten werden, während 40kbs es tun würden).

an dem Antwort-Header der Suche, wenn das tut abgeschnitten passieren:

{ 
    "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"; 
} 

Hat entweder nicht eine Glocke läuten. Jemand?

Answer 1

hatte ich das gleiche Problem:

Nginx einige Antworten aus dem FastCGI-Backend abgeschnitten. Zum Beispiel konnte ich keine korrekte SQL-Sicherung von PhpMyAdmin generieren. Ich habe die Protokolle und fanden diese:

2012/10/15 02:28:14 [Crit] 16443 # 0: * 14534527 open() „/ usr/local/nginx/fastcgi_temp/4/81/0000004814" failed (13: Erlaubnis verweigert ), während das Lesen vorgeschalteten, Auftraggeber: * server: , Anfrage: "POST/ HTTP/1.1" stromaufwärts „fastcgi: //127.0.0.1: 9000" , host: "", Referrer: „http: // */server_export.php Token = ** "

Alles, was ich tun musste, beheben es richtige Berechtigungen auf die /usr/local/nginx/fastcgi_temp Ordner sowie client_body_temp zu geben war.

Behoben!

Vielen Dank samvermette, Ihre Frage & Antwort hat mich auf dem richtigen Weg.

Answer 2

Sah meine nginx error.log Datei und fand folgendes:

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

Sieht aus wie nginx Proxy die Antwort Inhalte zu speichern versuchte (bestanden in durch dünne) in einer Datei. Dies ist nur der Fall, wenn die Antwortgröße proxy_buffers (64 KB standardmäßig auf 64-Bit-Plattform) überschreitet. Also am Ende war der Bug mit meiner Anfrage Antwortgröße verbunden.

Ich beendete die Behebung meines Problems, indem ich proxy_buffering auf off in meiner Nginx-Konfigurationsdatei setzte, statt proxy_buffers zu erhöhen oder das Dateiberechtigungs-Problem zu beheben.

Noch nicht sicher über den Zweck von Nginx Puffer. Ich würde mich freuen, wenn irgendjemand das summieren könnte. Ist das Deaktivieren der Pufferung komplett eine schlechte Idee?

Answer 3

Ich hatte ähnliches Problem mit schneiden Antwort vom Server. nur

Es geschah, als ich json Header hinzugefügt vor gzip Antwort header('Content-type: application/json');

In meinem Fall der Rückkehr verursacht das Problem.

I löste es durch gzip_types in nginx.conf Spezifizieren und Hinzufügen application/json bevor auf gzip Drehen aufzulisten:

gzip_types text/plain text/html text/CSS-Anwendung/x-JavaScript text/xml application/xml Anwendung/xml + rss Text/Javascript Anwendung/JSON;

gzip on; 

Answer 4

Es ist möglich, dass Sie aus Inodes lief, die richtig Nginx von der Nutzung des fastcgi_temp Verzeichnis verhindert.

Versuchen Sie df -i und wenn Sie 0% Inodes frei haben, ist das ein Problem.

Versuchen Sie find /tmp -mtime 10 (älter als 10 Tage) zu sehen, was Ihre Festplatte füllen könnte.

Oder vielleicht ist es ein anderes Verzeichnis mit zu vielen Dateien. gehen zum Beispiel auf /home/www-data/example.com und zählen Sie die Dateien:

find . -print | wc -l

Answer 5

Danke für die Frage und die großen Antworten, es hat mich gerettet viel Zeit. Am Ende half mir die Antwort von Clement und Sam, mein Problem zu lösen, also gehen die Credits an sie.

Ich wollte nur darauf hinweisen, dass es nach dem Lesen ein wenig über das Thema scheint, es ist nicht ratsam, proxy_buffering zu deaktivieren, da es Ihren Server zum Stillstand bringen könnte, wenn die Clients (Benutzer Ihres Systems) eine schlechte Internetverbindung haben .

Ich fand this discussion sehr nützlich, um mehr zu verstehen. Das Beispiel von Francis Daly machte es sehr klar für mich:

Vielleicht ist es einfacher, den vollständigen Prozesses als eine Kette von Prozessen zu denken.

Webbrowser spricht mit Nginx, über eine 1 MB/s Link. Nginx spricht mit dem Upstream-Server über eine 100 MB/s-Verbindung. Upstream-Server gibt 100 MB Inhalt an nginx zurück. Nginx gibt 100 MB Inhalt an den Webbrowser zurück.

Mit proxy_buffering auf, nginx kann die ganze 100 MB, halten so die nginx-Upstream-Verbindung kann nach 1 s geschlossen werden, und dann kann nginx 100 s verbringen den Inhalt an den Web-Browser gesendet wird.

Wenn proxy_buffering deaktiviert ist, kann nginx nur den Inhalt von Upstream bei mit der gleichen Rate wie nginx an den Webbrowser senden.

Der Webbrowser kümmert sich nicht um den Unterschied - es dauert immer noch 100 s, um den gesamten Inhalt zu erhalten.

nginx kümmert sich nicht viel um den Unterschied - es dauert immer noch 100 s bis Feed den Inhalt an den Browser, aber es muss die Verbindung zu Upstream für zusätzliche 99 s offen halten.

Upstream kümmert sich um den Unterschied - was könnte es genommen haben 1 s dauert tatsächlich 100 s; und für die zusätzlichen 99 s ist dieser Upstream-Server , der keine anderen Anfragen bedient.

Normalerweise: die Nginx-Upstream-Verbindung ist schneller als die Browser-Nginx-Verbindung; und Upstream ist mehr "Schwergewicht" als Nginx; so ist es ratsam, Upstream-Verarbeitung so schnell wie möglich zu beenden.

Answer 6

Ich habe auch dieses Problem habe - JSON Parsen clientseitige fehlerhaft war, die Reaktion wurde noch abgeschnitten oder noch schlimmer, die Antwort war abgestanden und wurde aus einem zufälligen Speicherpuffer gelesen.

Nach dem Durchlaufen einiger Anleitungen - Serving Static Content Via POST From Nginx sowie Nginx: Fix to “405 Not Allowed” when using POST serving static beim Versuch, nginx zu konfigurieren, um eine einfache Datei JSON zu dienen.

In meinem Fall musste ich benutze:

max_ranges 0; 

so dass der Browser keine lustigen Ideen bekommt, wenn nginx Accept-Ranges: bytes in der Antwort-Header) sowie

sendfile off; 

fügt

in meinem server Block für den Proxy, der die statischen Dateien dient. Hinzufügen zu dem location Block, der schließlich die gefundene Datei JSON dienen würde, hat nicht geholfen.

Eine weitere protip für statische JSON s auch dazu dient, nicht zu vergessen den Antworttyp würde:

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

Weitere Such ergaben Ordner Berechtigungsprobleme - nginx is cutting the end of dynamic pages and cache it oder Proxy-Pufferung Probleme - Getting a chunked request through nginx, aber das war nicht mein Fall.

Answer 7

Wir hatten ein ähnliches Problem. Es wurde von unserem REST-Server (DropWizard) verursacht, der SO_LINGER aktiviert hat. Unter Last löste DropWizard NGINX, bevor es die Möglichkeit hatte, seine Puffer zu löschen. Der JSON war> 8kb und das Frontend würde es abgeschnitten erhalten.