reverseproxy: Ignore context cancel in stream mode

[mholt]

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

[francislavoie]

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. Content-Type, bidirectional, Content-Length guessing logic) won't get this behaviour.

[mholt]

@francislavoie Yep. I do in the godoc comment in this patch. (I guess we'll want to update Caddyfile docs too.)

[wazerstar]

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
{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"url"}},"error":"reading: context canceled"}

then if I Add flush_interval -1 to reverse_proxy

outcome will become this
{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"url"}},"error":"writing: client disconnected"}

[mholt]

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.