Skip to content
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.

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

Fix http parsing for duplicate HTTP #887

Merged
merged 3 commits into from
May 29, 2024
Merged

Conversation

grcevski
Copy link
Contributor

@grcevski grcevski commented May 28, 2024

Our kprobes HTTP parsing had some edge case bugs:

  1. When detecting HTTP request end, we were only looking for HTTP, not HTTP/1. which is a bit more reliable.
  2. We could potentially reprocess the request start if subsequent packet had another GET and similar. Now we check if we'd already seen a request start for the given connection.
  3. We could potentially reprocess the end if subsequent response packet contained HTTP, after the initial. We now guard the http end processing with status == 0.

I believe this bug was accidentally introduced with our previous released addition for correct tracking of response times for large requests. Namely, previously we'd send the captured event as soon as we saw the HTTP/1.1 in the response. Now, we keep things alive until the client and server stop communicating, which exposed us to potentially re-parsing the HTTP end if we saw another HTTP.

Closes #885

@grcevski grcevski requested review from mariomac and marctc as code owners May 28, 2024 20:23
//HTTP
if ((p[0] == 'H') && (p[1] == 'T') && (p[2] == 'T') && (p[3] == 'P')) {
//HTTP/1.x
if ((p[0] == 'H') && (p[1] == 'T') && (p[2] == 'T') && (p[3] == 'P') && (p[4] == '/') && (p[5] == '1') && (p[6] == '.')) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be more specific on what you are looking for, HTTP is not enough.

@@ -337,6 +338,9 @@ static __always_inline void process_http_response(http_info_t *info, unsigned ch
info->status += (buf[RESPONSE_STATUS_POS] - '0') * 100;
info->status += (buf[RESPONSE_STATUS_POS + 1] - '0') * 10;
info->status += (buf[RESPONSE_STATUS_POS + 2] - '0');
if (info->status > MAX_HTTP_STATUS) { // we read something invalid
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Defensive measure to at reset the status if we parsed something incorrect, allowing us to potentially find the correct response (or at least set 0).

@codecov-commenter
Copy link

codecov-commenter commented May 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.12%. Comparing base (ccc8f20) to head (35375d2).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #887      +/-   ##
==========================================
- Coverage   77.57%   77.12%   -0.46%     
==========================================
  Files         122      122              
  Lines        8594     8594              
==========================================
- Hits         6667     6628      -39     
- Misses       1482     1522      +40     
+ Partials      445      444       -1     
Flag Coverage Δ
integration-test 55.66% <ø> (-0.05%) ⬇️
k8s-integration-test 61.49% <ø> (-0.09%) ⬇️
oats-test ?
unittests 43.42% <ø> (-0.06%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@grcevski grcevski merged commit a08e2ba into grafana:main May 29, 2024
6 checks passed
@grcevski grcevski deleted the fix_http_parsing branch May 29, 2024 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Invalid http_response_status_code reported
4 participants