nginx termina la connessione dopo 65k byte

Ho nginx configurato come front-end per un'applicazione Python in esecuzione su gunicorn, ma nginx sta terminando le connessioni dopo che sono stati inviati circa 65k di dati.

Ad esempio, ho una vista che assomiglia a questa:

def debug_big_file(request):
    return HttpResponse("x" * 500000)

Ma quando accedo a quell'URL tramite nginx, ottengo solo 65283 byte:

$ curl https://example.com/debug/big-file | wc
…
curl: (18) transfer closed with outstanding read data remaining
   0       1   65283

Si noti che tutto funziona come previsto quando si accede direttamente al gunicorn:

$ curl http://localhost:1234/debug/big-file | wc
…
   0       1   500000

La configurazione nginx pertinente:

location / {
    proxy_pass http://localhost:1234/;
    proxy_redirect off;
    proxy_headers_hash_bucket_size 96;
}

E nginx versione 1.7.0

Alcuni altri fatti:

Il numero di byte è coerente da una richiesta all'altra, ma varia in base al contenuto (l'ho notato per la prima volta con un file PNG di grandi dimensioni, che è stato tagliato dopo 65.372 byte, non 65.283)
110k byte vengono inviati correttamente (ovvero "x" * 110000restituisce tutti i 110.000 byte), ma 120k byte no
tcpdump suggerisce che nginx sta inviando un pacchetto RST a gunicorn:

nginx gunicorn

— David Wolever
fonte

Sarebbe utile vedere (a) come Gunicorn sta scegliendo di inquadrare le risposte da 110k a 120k byte di dimensione, e (b) come nginx sceglie quindi la sua inquadratura per lo stesso intervallo di dimensioni del payload del campione tra 110k e 120k byte. I tre modi in cui HTTP può inquadrare i dati: fornire lunghezza del contenuto; eseguire la codifica in blocchi; o non dare alcuna inquadratura se non per promettere di chiudere la presa quando il corpo è completo.

— Brandon Rodi,

È stata fornita un'intestazione di lunghezza del contenuto. Fammi scaricare il pacchetto per vedere cosa sta succedendo tra i due altrimenti ...

— David Wolever,

Hrm, molto strano. tcpdump suggerisce che nginx sta attivamente eseguendo RST sulla connessione (vedi modifica). nginx utilizza anche HTTP / 1.0 e Connection: close. Ho anche confermato che l' Content-Lengthintestazione è corretta.

— David Wolever,

Va bene! Dopo aver ricontrollato i registri nginx, questo si è rivelato essere il problema:

2014/05/26 16:50:56 [crit] 31396#0: *11 open() "…/proxy_temp/2/00/0000000002" failed (13: Permission denied) while reading upstream, client: 1.2.3.4, server: _, request: "GET /debug/big-file HTTP/1.1", upstream: "http://127.0.0.1:1234/debug/big-file", host: "example.com"

Alcuni come le autorizzazioni per la proxy_tempdirectory sono state incasinate, impedendo a nginx di eseguire correttamente il buffering.

— David Wolever
fonte

Sì, ho appena risolto un problema come questo, ho guardato nei registri di nginx, avevo una riga contenente

[crit] 6636#0: *16817 open() "/var/lib/nginx/proxy/7/03/0000000037" failed (13: Permission denied) while reading upstream

, fatto sudo chown -R www-data:www-data /var/lib/nginx/e si è risolto.

— Epigene,