http server: chunk extensions rejected, connection closed with no response

Đang mở
  • Có gì không ổn?
#12,648 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
56/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
backend

Hướng nghiên cứu

Start with lib/monkey/mk_server/mk_http_parser.c, especially http_parser_transfer_encoding_chunked() and the check at line 606 described in the report. Reproduce with the supplied chunked request and compare it with the 7 control case. Done means chunk extensions are accepted and the request receives the expected response; the related malformed-input response behavior may need separate scope.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Bug Report

Describe the bug

The HTTP server rejects any chunked request that uses a chunk extension (RFC 9112 §7.1.1, formerly
RFC 7230 §4.1) and closes the connection without sending any HTTP response at all — not a 400, nothing.
The client sees a bare EOF and cannot distinguish it from a transport failure.

To Reproduce

Start an http input on port 9880, then send this raw request:

POST / HTTP/1.1
Host: x
Content-Type: application/json
Transfer-Encoding: chunked

7;a=b\r\n{"a":1}\r\n0\r\n\r\n

Result: connection closed immediately (EOF at 0.00 s), no response bytes. The server itself stays healthy
and the next request returns 201.

All of these fail identically:

chunk-size line result
7;a=b EOF, no response
7; (empty extension) EOF, no response
7;a="b c" (quoted value) EOF, no response
0;a=b (terminator with extension) EOF, no response
7 (trailing space) EOF, no response
7 (control) 201

Chunked itself works fine otherwise: splitting the body across chunks, one byte per chunk, and uppercase hex
all return 201. Reproduces on the monitoring server (:2020) as well.

Root cause

lib/monkey/mk_server/mk_http_parser.c, http_parser_transfer_encoding_chunked():

memcpy(tmp, p->chunk_processed_start, len);   /* whole chunk-size line, up to CRLF */
tmp[len] = '\0';

chunk_len = strtol(tmp, &ptr, 16);
...
if (ptr == tmp || *ptr != '\0') {             /* line 606 */
    return MK_HTTP_PARSER_ERROR;
}

The parser copies the entire chunk-size line and then requires strtol to have consumed all of it.
strtol stops at the ;, so *ptr is ; and the request is treated as a parse error. The same check also
rejects a trailing space after the size.

Expected behavior

The extension should be ignored (or parsed) and the chunk length taken from the hex prefix, so the request
succeeds with 201.

Second, related issue

Every MK_HTTP_PARSER_ERROR closes the connection with no response, so malformed chunked input is
indistinguishable from a network drop (a plain ZZZ chunk size behaves the same way). A 400 would be the
expected behaviour.

Your Environment

  • Fluent Bit 5.1.5 (fluent/fluent-bit:latest), also present on current master — the lines above are
    unchanged there
  • Linux, aarch64, official container image
  • Input: http plugin, default settings

Impact

Any client, proxy or SDK that emits chunk extensions gets a silent failure with no status code and nothing
to log or retry on. 0;a=b means even a correctly terminated body fails.

Ngôn ngữ chính
C
Star
8.2k
Fork
2k
Merge trung bình
3 ngày 20 giờ
Pull request đã merge (30 ngày)
99

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của fluent/fluent-bit

Tất cả issue của fluent/fluent-bit

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.