Skip to content

check_curl: accept non standard compliant status line #2169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
RincewindsHat merged 2 commits into from
Oct 31, 2025
Merged

check_curl: accept non standard compliant status line #2169

RincewindsHat merged 2 commits into from
Oct 31, 2025

Conversation

@RincewindsHat
Copy link
Member

@RincewindsHat RincewindsHat commented Oct 30, 2025

If the status line from a server ended with '\n' instead of '\r\n' (defined by RFC 9112), check_curl failed to parse it and exited with an alarm.
The RFC recommends to be lenient here and this change follows that suggestion.

@RincewindsHat
check_curl: accept non standard compliant status line
669edf2 
If the status line from a server ended with '\n' instead
of '\r\n' (defined by RFC 9112), check_curl failed to parse it
and exited with an alarm.
The RFC recommends to be lenient here and this change follows that
suggestion.
@RincewindsHat RincewindsHat marked this pull request as ready for review October 30, 2025 20:46
@RincewindsHat
Copy link
Member Author

RincewindsHat commented Oct 30, 2025

Experienced that problem with a GoAhead embedded webserver

@RincewindsHat
Copy link
Member Author

RincewindsHat commented Oct 30, 2025

pinging @andreasbaumann here, too :-)

@andreasbaumann
Copy link
Contributor

andreasbaumann commented Oct 31, 2025 •
edited
Loading

There was security issues around being to lenient when parsing such newline-
terminated protocols (CRLF-injection, HTTP header/body splits in wrong places
can lead to reading the wrong part as header or body). Same was possible in
SMTP IIRC (with old newlines from old mail clients being lenient when parsing
the lines).

Adding an option like --lenient-parsing is maybe an option..

The RFC is long and hard to read (and to implement), if we do something the
standard says, is correct, then yes, we don't need an option for this.

libcurl has no HTTP header parser as far as I can see, that's the reason there
is a special piece of code for that.

@RincewindsHat
Copy link
Member Author

RincewindsHat commented Oct 31, 2025

Hm, I am going to merge this as is then and we push this discussion for special options into the future for other cases.

Thank you for the feedback.

@RincewindsHat RincewindsHat merged commit 8a4d8bc into monitoring-plugins:master Oct 31, 2025
7 checks passed
@RincewindsHat RincewindsHat deleted the check_curl_line_endings branch October 31, 2025 11:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@andreasbaumann andreasbaumann andreasbaumann approved these changes

Assignees

No one assigned

Labels

check_curl

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@RincewindsHat @andreasbaumann