Articolo del tipo «appunti nel margine».
TL:DR:
http2_max_field_size 8k; # tutti salveranno!In un progetto, dopo aver modificato una certa logica interna del backend, ho iniziato a notare un strano response_code nei log, precisamente — 0. Nei log appare più o meno così:
{
"timestamp": "2020-01-17T08:41:51+00:00",
"remote_addr": "zzz.zzz.zzz.zzz",
"request_time": 0,
"upstream_response_time": "",
"upstream_header_time": "",
"http_accept_language": "-language",
"response_status": 0,
"request": "",
"host": "example.com",
"upstream_addr": "",
"http_referrer": "",
"request_length": 5854,
"bytes_sent": 0,
"http_user_agent": ""
}
Leggere la documentazione e cercare su Google su questo argomento non ha portato a nulla — poiché si afferma che tale comportamento si verifica quando il client ha chiuso la connessione senza inviare le intestazioni. E un po' di stranezze con la dimensione del buffer per wsgi_, che nel nostro caso non è affatto adatta.
In generale, abbiamo deciso che il problema non è un problema, considerando che nei nostri volumi non è affatto critico.
Fino al momento in cui non mi è stata posta la seguente domanda: in alcuni casi i link si aprono senza problemi tramite http, ma rifiutano categoricamente di funzionare tramite https, restituendo un meraviglioso: Connection #0 to host example.com left intact
curl: (52) Risposta vuota dal server
Nei log, è stato possibile risalire a questa cosa solo tramite IP — né richieste né altri dati, come si può vedere dall'esempio sopra — ci sono. Solo il famigerato stato 0, ma so che non ho interrotto la richiesta! Ho iniziato a scavare su cosa potesse andare storto. E la soluzione è stata molto semplice:
listen 443 ssl http2 backlog=8192;
Quindi, se si utilizza http2 per connessioni ssl, non basta configurare solo i buffer della richiesta, ma è necessario configurarli anche in ngx_http_v2_module, e precisamente:
Sintassi: http2_max_field_size dimensione;
Valore predefinito: http2_max_field_size 4k;
Contesto: http, server
Limita la dimensione massima dell'intestazione della richiesta, compressa con HPACK. Il limite si applica ugualmente sia al nome che al valore. Se viene utilizzata la codifica di Huffman, la dimensione effettiva delle stringhe non compresse può essere maggiore. Il limite predefinito è adeguato per la maggior parte delle richieste.
In generale, è questo. E perché? Perché la lunghezza del link era grande — più di 4k.
Impostandolo, ad esempio, su 8kb (o quanto basta sicuramente) — risolviamo il problema.
Ecco fatto.
Fonte: habr.com
