Ein Artikel aus der Kategorie 'Notizen am Rande'.
TL:DR:
http2_max_field_size 8k; # das wird helfen!In einem unserer Projekte, nach einer Änderung in der internen Logik des Backends, beobachtete ich einen seltsamen response_code in den Logs, nämlich — 0. In den Logs sieht das ungefähr so aus:
{
"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": ""
}
Das Studium der Dokumentation und das Googeln zu diesem Thema hat mir nichts gebracht – da behauptet wird, dass ein solches Verhalten auftritt, wenn der Client die Verbindung schließt, ohne Header zu übermitteln. Und die ganze Exotik bezüglich der Buffergröße für wsgi_, was in unserem Fall überhaupt nicht passte.
Insgesamt kamen wir zu der Entscheidung, dass das Problem — kein Problem ist, da es bei unseren Volumina völlig unkritisch ist.
Genau bis zu dem Moment, als ich mit dem nächsten Problem konfrontiert wurde: In einigen Fällen öffnen sich die Links problemlos über http, funktionieren aber überhaupt nicht über https und erzeugen die wunderbare Meldung: Connection #0 to host example.com left intact
curl: (52) Leere Antwort vom Server
In den Protokollen konnte dieses Problem nur über die IP nachverfolgt werden — weder Requests noch andere Daten, wie im obigen Beispiel zu sehen ist, sind vorhanden. Nur der berüchtigte Status 0, aber ich weiß, dass ich die Anfrage nicht unterbrochen habe! Ich begann zu untersuchen, was schiefgehen könnte. Und es stellte sich als ganz einfach heraus:
listen 443 ssl http2 backlog=8192;
So, wenn http2 für SSL-Verbindungen verwendet wird, reicht es nicht aus, nur die Anfrage-Puffer zu konfigurieren; sie müssen auch im ngx_http_v2_module konfiguriert werden, und zwar:
Syntax: http2_max_field_size size;
Voreinstellung: http2_max_field_size 4k;
Kontext: http, server
Begrenzt die maximale Größe des über HPACK komprimierten Anfrage-Headers. Die Beschränkung gilt gleichermaßen für den Namen und den Wert. Bei Verwendung der Huffman-Codierung kann die tatsächliche Größe der entpackten Namen und Werte größer sein. Die voreingestellte Begrenzung ist für die meisten Anfragen geeignet.
Im Grunde ist es das. Und warum? Weil die URL zu lang war — länger als die besagten 4k.
Wenn man sie beispielsweise auf 8kb (oder so viel, wie man sicher braucht) setzt, löst man das Problem.
So steht's.
Quelle: habr.com
