Een artikel uit de categorie "notities in de marge".
TL: DR:
http2_max_field_size 8k; # всех спасет!Bij een van de projecten begon ik, na wat interne logica van de backend te hebben aangepast, een vreemde response_code in de logs te zien, namelijk - 0. In de logs ziet het er ongeveer zo uit:
{
"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": ""
}
Na het lezen van de documentatie en het googelen over dit onderwerp heb ik absoluut niets gevonden. Er wordt beweerd dat dit gedrag optreedt als de client de verbinding sluit zonder headers te versturen. Nou ja, en allerlei exotische dingen met de buffergrootte voor wsgi_, die in ons geval helemaal niet geschikt was.
Al met al zijn we tot de conclusie gekomen dat het probleem geen probleem is, aangezien het bij onze volumes helemaal niet kritiek is.
Tot het moment dat ik me het volgende probleem realiseerde: in sommige gevallen openen links zonder problemen via http, maar weigeren volledig te werken via https, waardoor het prachtige resultaat ontstaat: Verbinding #0 naar host example.com blijft intact
curl: (52) Leeg antwoord van server
In de logs konden we dit enkel traceren op basis van het IP-adres. Er was geen verzoek of andere data, zoals u in het bovenstaande voorbeeld kunt zien. Alleen de beruchte status 0, maar ik weet dat ik het verzoek niet heb onderbroken! Ik begon rond te snuffelen om te zien wat er mis kon gaan. Maar het bleek allemaal heel eenvoudig te zijn:
luister 443 ssl http2 achterstand=8192;
Als u http2 gebruikt voor SSL-verbindingen, is het niet voldoende om alleen de aanvraagbuffers te configureren. U moet deze ook configureren in ngx_http_v2_module, namelijk:
Синтаксис: http2_max_field_size размер;
Умолчание: http2_max_field_size 4k;
Контекст: http, server
Beperkt de maximale grootte van een aanvraagheader die is gecomprimeerd met HPACK. De beperking geldt voor zowel de naam als de waarde. Als Huffman-codering wordt gebruikt, kan de werkelijke grootte van de uitgepakte naam- en waardereeksen groter zijn. De standaardlimiet is geschikt voor de meeste query's.
Nou, dat is alles. En waarom dit allemaal? Omdat de linklengte lang was - langer dan diezelfde 4k.
Door de waarde bijvoorbeeld in te stellen op 8 kB (of zoveel als waarschijnlijk voldoende is), lossen we het probleem op.
Zulke dingen.
Bron: www.habr.com
