[Nginx] როგორ დავამარცხოთ answer_status = 0

სტატია კატეგორიიდან "გვერდითი ნოტები".

TL: DR:

http2_max_field_size 8k; # всех спасет!

ერთ-ერთ პროექტზე, უკანა ნაწილის შიდა ლოგიკის შეცვლის შემდეგ, დავიწყე ლოგებში უცნაური answer_code-ის დაკვირვება, კერძოდ 0. ჟურნალებში ეს ასე გამოიყურება:

{
  "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": ""
}

დოკუმენტაციის წაკითხვამ და გუგლმა ამ თემაზე აბსოლუტურად არაფერი გამოიღო - რადგან... ნათქვამია, რომ ეს ქცევა ხდება მაშინ, როდესაც კლიენტმა დახურა კავშირი სათაურების გადაცემის გარეშე. ისე, და სხვადასხვა ეგზოტიკური ნივთები ბუფერული ზომით wsgi_-სთვის, რაც ჩვენს შემთხვევაში არ ერგებოდა სიტყვას „არანაირად“.

ზოგადად, ჩვენ გადავწყვიტეთ, რომ პრობლემა არ არის პრობლემა, იმის გათვალისწინებით, რომ ჩვენს ტომებში ის საერთოდ არ არის კრიტიკული.

ზუსტად მანამ, სანამ არ გამიკვირდა შემდეგი პრობლემა: ზოგიერთ შემთხვევაში, ბმულები უპრობლემოდ იხსნება http-ის საშუალებით, მაგრამ სრულიად უარს ამბობს https-ის საშუალებით მუშაობაზე, რაც წარმოქმნის მშვენიერს: კავშირი #0 ჰოსტინგის მაგალითი.com-ზე დარჩა ხელუხლებელი.
curl: (52) ცარიელი პასუხი სერვერიდან

ჟურნალებში ჩვენ შევძელით ამ ნივთის თვალყურის დევნება მხოლოდ IP-ით - არ ყოფილა არანაირი მოთხოვნა ან რაიმე სხვა მონაცემი, როგორც ეს ზემოთ მოყვანილი მაგალითიდან ჩანს. მხოლოდ ყბადაღებული სტატუსია 0, მაგრამ ვიცი, რომ მოთხოვნა არ შემიწყვეტია! დავიწყე იმის გარკვევა, თუ რისი გაკეთება შეიძლება არასწორედ. და ყველაფერი ძალიან მარტივი აღმოჩნდა:

მოუსმინე 443 სსლ http2 ჩამორჩენილი =8192;

კარგად, თუ იყენებთ http2 ssl კავშირებისთვის, მაშინ საკმარისი არ არის მხოლოდ მოთხოვნის ბუფერების კონფიგურაცია, ისინი ასევე უნდა იყოს კონფიგურირებული ngx_http_v2_module-ში, კერძოდ:

Синтаксис:	http2_max_field_size размер;
Умолчание:	http2_max_field_size 4k;
Контекст:	http, server

ზღუდავს HPACK-ის გამოყენებით შეკუმშული მოთხოვნის სათაურის მაქსიმალურ ზომას. შეზღუდვა თანაბრად ვრცელდება როგორც სახელზე, ასევე მნიშვნელობაზე. თუ გამოყენებულია ჰაფმანის კოდირება, შეუფუთავი სახელისა და მნიშვნელობის სტრიქონების რეალური ზომა შეიძლება იყოს უფრო დიდი. ნაგულისხმევი ლიმიტი შესაფერისია მოთხოვნების უმეტესობისთვის.

ზოგადად, ეს ასეა. და რატომ ყველა? იმის გამო, რომ ბმულის სიგრძე იყო გრძელი - უფრო გრძელი ვიდრე იგივე 4K.

მაგალითად, 8 კბ-ზე დაყენებით (ან იმდენი, რამდენიც სავარაუდოდ საკმარისი იქნება), ჩვენ პრობლემას ვაგვარებთ.
ასეთი შემთხვევები.

წყარო: www.habr.com