Disabled bare LF in chunked transfer encoding. #1016
Conversation
|
Change itself looks straightforward. |
src/http/ngx_http_parse.c
Outdated
| switch (state) { | ||
|
|
||
| case sw_chunk_start: | ||
| ctx->length = 3 /* "0" LF LF */; |
There was a problem hiding this comment.
Should ctx->length be corrected after bare LF is disabled?
There was a problem hiding this comment.
Yes, it needs to be adjusted. Also updated initial u->pipe->length in the proxy module,
and disabled bare LF in a trailer section for similar reasons; see 1c79a4e.
ctx->length is used to hint how much data we expect to receive.
It is important to not over-estimate as this may result in blocked request processing
as fixed in 88fc0f7.
In contrast, underestimating ctx->length may result in less efficient chunked processing,
because parser will be called more often than it might be.
On the client-facing side, ctx->length sets the remaining request body (rb->rest).
This is now largely irrelevant since after 150cbb0 we're prepared to read additional data
from the next pipelined request. Also, the chunked parser is called here whenever new data is received.
On the upstream side, ctx->length is used to buffer data in the event pipe when reading
from upstream until u->pipe->length is received, before invoking input filter to parse chunks.
|
On Thu, 04 Dec 2025 13:40:59 -0800 VadimZhestikov ***@***.***> wrote:
@VadimZhestikov commented on this pull request.
Should ctx->length be corrected after bare LF is disabled?
Hmm, don't we just bail out and return NGX_ERROR in such cases now?
|
ctx->length is minimal amount of data we want to see (this value is used in callers), and now looks like this value need to be increased, since in place of LF we expect always CR LF |
Chunked transfer encoding, since originally introduced in HTTP/1.1 in RFC 2068, is specified to use CRLF as the only line terminator. Although tolerant applications may recognize a single LF, formally this covers the start line and fields, and doesn't apply to chunks. Strict chunked parsing is reaffirmed as intentional in RFC errata ID 7633, notably "because it does not have to retain backwards compatibility with 1.0 parsers". A general RFC 2616 recommendation to tolerate deviations whenever interpreted unambiguously doesn't apply here, because chunked body is used to determine HTTP message framing; a relaxed parsing may cause various security problems due to a broken delimitation. For instance, this is possible when receiving chunked body from intermediates that blindly parse chunk-ext or a trailer section until CRLF, and pass it further without re-coding.
3 participants
Chunked transfer encoding, since originally introduced in HTTP/1.1 in RFC 2068, is specified to use CRLF as the only line terminator.
Although tolerant applications may recognize a single LF (discussed previously at [1]), formally this covers the start line and fields, and doesn't apply to chunks. Strict chunked parsing is reaffirmed as intentional in RFC errata ID 7633, notably "because it does not have to retain backwards compatibility with 1.0 parsers".
A general RFC 2616 recommendation to tolerate deviations interpreted unambiguously barely applies to chunks as they are used to determine HTTP message framing, and ambiguity may result in potentially broken delimitation. In contrast, accepting a single LF may pose an extra condition for potential request smuggling in complex scenarios. For instance, this is possible when receiving chunks from intermediates that misinterpret LF as part of a valid chunk-ext-name and pass it further without re-coding. The change aims to address this as well.
[1] https://mailman.nginx.org/pipermail/nginx-devel/2024-January/5CQQCHFYQMXTBAK7H2FITLVQQS5ECFFM.html