Quando Rails risponde con "transfer-encoding" e "content-length"?

Question

Sto costruendo un'API su Rails versione 4.1.7/Nginx che risponde alla richiesta da un'app iOS. Stiamo assistendo a qualche strana memorizzazione nella cache sul client e pensiamo che abbia qualcosa a che fare con una piccola differenza nella risposta che Rails sta rinviando. Le mie domande ...

1) Voglio capire perché, per la stessa identica richiesta (con solo il valore di intestazione di autorizzazione modificato), Rails restituisce talvolta transfer-encoding: chunked e Content-Length: <number>? Ho pensato che forse aveva qualcosa a che fare con le dimensioni della risposta, ma nelle risposte di esempio di cui ho incollato le intestazioni sotto, i dati restituiti nel corpo sono ESATTAMENTE uguali.

2) C'è un modo per forzare l'utilizzo di Content-Length? Pensiamo che ciò risolverà i problemi di memorizzazione nella cache nella nostra app iOS.

Risposta # 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 

Richiesta # 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

Entrambe le risposte sono validi in base al HTTP 1.1, quindi è necessario correggere il codice client che può gestire entrambe le cose. È una cattiva idea provare a riparare il server in modo che si comporti in modo tale da non innescare un bug nel client. La prossima versione di nginx potrebbe comportarsi diversamente, gli utenti potrebbero persino avere proxy che modificano il trasferimento, forse solo quando effettuano il roaming e utilizzano un provider diverso.

Se si desidera eseguire delle impronte digitali sull'intestazione, l'intestazione ETag può essere d'aiuto, poiché l'ETag deve rimanere costante quando il contenuto della risposta non viene modificato, indipendentemente dal trasferimento.

Il server invia in genere in blocchi quando chiama una pagina dinamica, perché allora non ha bisogno di creare un buffer per l'intera pagina e aspettare che tutta la pagina viene generata.

Il server spesso inviare la risposta in un colpo solo se ha il buffer già, ad esempio, perché è nella cache o il contenuto è su un file e non è di grande. L'invio in un colpo solo è più efficiente, d'altra parte, una copia extra dei dati per bufferizzare l'output richiede più memoria ed è meno efficiente. Quindi il server può persino decidere in base alla memoria disponibile.