http_server: accept empty HTTP header values - #12175
Conversation
📝 WalkthroughWalkthroughThe HTTP parser now accepts empty and whitespace-only header values, finalizes them normally, and continues header processing. The runtime HTTP test sends requests containing both forms and asserts that the server returns HTTP 201. ChangesEmpty header values
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant HTTPClient
participant HTTPServer
participant mk_http_parser
HTTPClient->>HTTPServer: Send request with empty header values
HTTPServer->>mk_http_parser: Parse header value
mk_http_parser-->>HTTPServer: Finalize empty value and continue
HTTPServer-->>HTTPClient: Return HTTP 201 response
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/monkey/mk_server/mk_http_parser.c`:
- Around line 999-1008: Update the MK_HEADER_HOST handling in header_lookup to
reject zero-length Host values, including values empty after optional
whitespace, while preserving acceptance of non-empty Host headers and generic
empty-header behavior.
In `@tests/runtime/in_http.c`:
- Line 454: Update the test around send_empty_header_request() so the request
uses a distinguishable payload, then assert that the corresponding output or
callback is observed directly. Ensure the later num > 0 check cannot be
satisfied by the preceding ordinary POST alone.
- Around line 379-395: Update the request/response logic around send(),
setsockopt(), and recv() to handle partial TCP writes and reads: loop until all
request bytes are sent, validate setsockopt() success, and accumulate response
data across recv() calls until the header terminator "\r\n" is found or the
buffer is full. Preserve null termination and reject send, socket-option,
receive, and incomplete/invalid response failures.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2d4fe72f-846a-4a04-9793-54b1aeb8d981
📒 Files selected for processing (2)
lib/monkey/mk_server/mk_http_parser.ctests/runtime/in_http.c
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56fc47e6b3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (buffer[p->i] == '\r') { | ||
| p->header_val = p->i; | ||
| mark_end(); | ||
|
|
||
| ret = header_lookup(p, buffer); |
There was a problem hiding this comment.
Avoid semantic scans from empty header values
When an empty known header reaches header_lookup, header->val.len becomes 0; for Transfer-Encoding: that length is passed to mk_string_search_n, whose len <= 0 path falls back to scanning the NUL-terminated remainder of the request. In plugins/in_http/http_conn.c the buffer is NUL-terminated before parsing, so a request like Transfer-Encoding:\r\nContent-Length: ...\r\n\r\n{"msg":"chunked"} is misclassified as chunked and mk_http_parser_ok returns pending instead of processing the Content-Length body. Please either reject empty semantic headers such as Transfer-Encoding or bypass their value parsing when the value length is zero.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Correction: commit 2d920dd now bypasses zero-length Transfer-Encoding semantic scanning, preventing mk_string_search_n from reading beyond the field. Empty Host and Content-Length remain rejected.
2a9298a to
2d920dd
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
Accept empty generic HTTP/1.1 field values, including values containing only optional whitespace. The parser previously returned an error before request completion, while the HTTP/1 server discarded that error and left keep-alive clients without a response. Add an in_http runtime regression request covering both empty-value wire forms. Reject empty semantic Upgrade values, avoid scanning beyond empty Connection and Transfer-Encoding fields, and close HTTP/1 sessions on parser errors. The runtime regression also verifies that an invalid empty Upgrade header closes the connection. Fixes fluent#12174. The focused Monkey parser and HTTP server libraries build successfully. The complete runtime test target is blocked in this environment by unrelated in_tail Flex/Bison-generated multiline dependencies. Signed-off-by: kimonus <kimonus@users.noreply.github.com>
2d920dd to
1feac14
Compare
Fixes #12174.
Summary
The Monkey HTTP/1 parser rejected syntactically valid generic headers with an
empty field value. The HTTP/1 server then discarded the parser error, leaving
keep-alive clients without a response.
This change accepts empty generic field values, including values containing
only optional whitespace. Semantic validation for headers such as Host and
Content-Length remains unchanged.
Testing
tests/runtime/in_http.cpasses compiler syntax checking.Header:\r\nandHeader: \r\nforms.flb-rt-in_httptarget could not be built locally because thischeckout's unrelated
in_tailbuild requires unavailable Flex/Bison-generatedmultiline APIs.
No packaging changes are included.
Summary by CodeRabbit
Bug Fixes
Tests