🥇[Nginx] How to defeat response_status = 0

An article from the category of "marginal notes".

TL:DR:

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

On one of the projects, after changing some internal backend logic, I started to observe a strange response_code in the logs, namely 0. In the logs it looks something like this:

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

Reading the documentation and googling on this topic gave absolutely nothing - because. this behavior is said to occur when the client closed the connection without sending the headers. Well, different exotics with the size of the buffer for wsgi_, which in our case did not fit the word “no way”.

In general, we decided that the problem is not a problem, given that it is absolutely not critical at our volumes.

Exactly until the moment when I was puzzled by the following problem: in some cases, links open without problems over http, but completely refuse to work over https, giving out a wonderful: Connection #0 to host example.com left intact
curl: (52) Empty reply from server

In the logs, it was possible to track this thing only by IP - neither a request, nor any other data, as can be seen from the example above - no. Only the notorious status 0, but I know that I did not interrupt the request! Began to pick what could go wrong. And everything turned out to be very simple:

listen 443 ssl http2 backlog=8192;

Well, if you use http2 for ssl connections, then it’s not enough just to configure request buffers, they must also be configured in ngx_http_v2_module, namely:

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

Limits the maximum size of a request header compressed with HPACK. The restriction applies equally to both the name and the value. If Huffman encoding is used, then the actual size of the unpacked name and value strings may be larger. The default limit is fine for most requests.

In general, this is it. And all why? Because the length of the link was large - more than those same 4k.

By exposing it to, for example, 8kb (or as much as is probably enough) - we solve the problem.
So it goes.

Source: habr.com

[nginx] How to defeat response_status = 0

Add a comment Отменить ответ