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: subroute blocking if all client data was already read #194

Merged
merged 1 commit into from
May 25, 2024

Conversation

ydylla
Copy link
Collaborator

@ydylla ydylla commented May 25, 2024

Copy link
Owner

@mholt mholt left a comment

Choose a reason for hiding this comment

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

This is great, thanks for the fix, and for the helpful explanatory comments!

@mholt mholt merged commit 83ccc7e into master May 25, 2024
6 checks passed
@IceCodeNew IceCodeNew deleted the fix-subroute branch May 27, 2024 02:38
ydylla added a commit that referenced this pull request Jun 6, 2024
This happens for example with the proxy_protocol matcher and handler. If we receive a proxy proto header from a not allowed source the matcher matches, but the handler does not consume any of the prefetched bytes. Since the handler is not terminal we jump back to the beginning of the matching loop and match the same matcher/handler combo again. It never stops because we never call cx.prefetch again. Since `isFirstPrefetch = false` is unreachable in this situation (the statement is at the wrong place). It always must be set false after the first iteration.
This bug was caused by the fix for #194
@ydylla ydylla mentioned this pull request Jun 6, 2024
mholt pushed a commit that referenced this pull request Jun 28, 2024
This happens for example with the proxy_protocol matcher and handler. If we receive a proxy proto header from a not allowed source the matcher matches, but the handler does not consume any of the prefetched bytes. Since the handler is not terminal we jump back to the beginning of the matching loop and match the same matcher/handler combo again. It never stops because we never call cx.prefetch again. Since `isFirstPrefetch = false` is unreachable in this situation (the statement is at the wrong place). It always must be set false after the first iteration.
This bug was caused by the fix for #194
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.

2 participants