-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
reverseproxy: Ignore context cancel in stream mode #4952
Conversation
A first attempt at resolving #4922
I guess we'll need to document that it must be explicitly configured to get this behaviour, and that relying on the detection stuff (i.e. |
@francislavoie Yep. I do in the godoc comment in this patch. (I guess we'll want to update Caddyfile docs too.) |
Has this been implemented? I cannot see any thing about this in change-log on release page. I'm testing some streaming and using hdhomerun, when client leaves,stops,change channel without using "flush_interval -1" The outcome is this then if I Add flush_interval -1 to reverse_proxy outcome will become this |
Yes, it was released; I'm not sure why it didn't make it into the release notes, but it's definitely released with v2.6. If you open a new issue with instructions to minimally reproduce the behavior we can look into it. |
This behavior might possibly be changing, by splitting it out into a separate config option other than See 8c9e87d -- for now I've implemented a new option, |
…eam mode i.e. Revert commit f5dce84 Two years ago, the patch in #4952 was a seemingly necessary way to fix an issue (sort of an edge case), but it broke other more common use cases (see #6666). Now, as of #6669, it seems like the original issue can no longer be replicated, so we are reverting that patch, because it was incorrect anyway. If it turns out the original issue returns, a more proper patch may be in #6669 (even if used as a baseline for a future fix). A potential future fix could be an opt-in setting.
…eam mode i.e. Revert commit f5dce84 Two years ago, the patch in #4952 was a seemingly necessary way to fix an issue (sort of an edge case), but it broke other more common use cases (see #6666). Now, as of #6669, it seems like the original issue can no longer be replicated, so we are reverting that patch, because it was incorrect anyway. If it turns out the original issue returns, a more proper patch may be in #6669 (even if used as a baseline for a future fix). A potential future fix could be an opt-in setting.
If FlushInterval is explicitly configured to -1, we assume the user is intending for low-latency streaming, and apparently in those cases clients sometimes disconnect before the request has finished its round-trip with the backend.
This patch ignores the client disconnect in those cases so the request will still be completed without error.
Even though
flushInterval()
is dynamically computed, for now I'm requiring an explicit configuration of -1 because I don't fully know the implications of this yet. It might be fine, but if there's problems I want them to be opt-in.We do know this solution at least works though.
Resolves #4922