Wann reagiert Rails mit 'Transfer-Encoding' vs. 'Content-Length'?

Question

Ich baue eine API auf Rails Version 4.1.7/Nginx, die auf Anfrage von einer iOS App reagiert. Wir sehen auf dem Client ein seltsames Caching, und wir denken, dass es etwas mit einem kleinen Unterschied in der Antwort zu tun hat, den Rails zurücksendet. Meine Fragen ...

1) Ich möchte verstehen, warum für die exakt gleiche Anfrage (mit nur der Authorization-Header-Wert geändert), sendet Rails manchmal transfer-encoding: chunked manchmal und Content-Length: <number> manchmal? Ich dachte, dass es vielleicht etwas mit der Antwortgröße zu tun hat, aber in den Beispielantworten, deren Header ich unten eingefügt habe, sind die im Körper zurückgegebenen Daten GENAU die gleichen.

2) Gibt es eine Möglichkeit, es zu zwingen, Content-Length zu verwenden? Wir denken, dass dies unsere Caching-Probleme in unserer iOS App beheben wird.

Antwort # 1

HTTP/1.1 200 OK 
Cache-Control: max-age=0, private, must-revalidate 
Content-Type: application/json; charset=utf-8 
Date: Wed, 18 Mar 2015 00:59:31 GMT 
ETag: "86f277ea63295460d4f3bed9a073eaa2" 
Server: nginx/1.6.2 
Status: 200 OK 
X-Content-Type-Options: nosniff 
X-Frame-Options: SAMEORIGIN 
X-Request-Id: dd36f139-1986-4da6-9645-4438d41e74b0 
X-Runtime: 0.123865 
X-XSS-Protection: 1; mode=block 
transfer-encoding: chunked 
Connection: keep-alive 

Antrag # 2

HTTP/1.1 200 OK 
Cache-Control: max-age=0, private, must-revalidate 
Content-Type: application/json; charset=utf-8 
Date: Wed, 18 Mar 2015 00:59:36 GMT 
ETag: "86f277ea63295460d4f3bed9a073eaa2" 
Server: nginx/1.6.2 
Status: 200 OK 
X-Content-Type-Options: nosniff 
X-Frame-Options: SAMEORIGIN 
X-Request-Id: 0cfd7705-157b-41b5-aa36-739bc6f8302e 
X-Runtime: 0.092672 
X-XSS-Protection: 1; mode=block 
Content-Length: 2234 
Connection: keep-alive 

Answer 1

Beide Antworten sind gültig nach HTTP 1.1, so dass Sie Ihren Client-Code beheben müssen, dass sie sowohl verarbeiten kann. Es ist eine schlechte Idee, den Server so zu reparieren, dass er sich so verhält, dass er keinen Fehler im Client auslöst. Die nächste Version von nginx kann sich anders verhalten, Sie haben möglicherweise sogar Proxies, die die Übertragung ändern, möglicherweise nur, wenn sie Roaming durchführen und einen anderen Provider verwenden.

Wenn Sie etwas Fingerdruck auf der Kopfzeile machen möchten, kann die ETag-Kopfzeile Ihnen helfen, da die ETag konstant bleiben sollte, wenn der Inhalt der Antwort unabhängig von der Übertragung nicht geändert wird.

Der Server sendet in der Regel Chunks, wenn er eine dynamische Seite aufruft, da er dann keinen Puffer für die gesamte Seite erstellen und warten muss, bis die gesamte Seite generiert ist.

Der Server sendet oft die Antwort auf einmal, wenn er den Puffer bereits hat, zum Beispiel weil er im Cache ist oder der Inhalt in einer Datei ist und nicht zu groß ist. Das Senden auf einmal ist effizienter, auf der anderen Seite benötigt eine zusätzliche Kopie der Daten zum Puffern der Ausgabe mehr Speicher und ist weniger effizient. So kann der Server dies sogar entsprechend dem verfügbaren Speicher entscheiden.