Open bjosv opened 10 months ago
I think Gun cannot know whether a stream is long polling or not. I therefore would not favor a feature where Gun ends streams based on a single per-connection option. On the other hand, a per-request (ReqOpts
) option sounds fine, especially since you can tweak the value depending on the request (if some responses take longer to be generated than others). Gun will have to send a gun_error
with an adequate error reason to identify why the request was terminated.
The guide can of course be updated but do that after sending a PR for the timeout feature preferrably.
I can implement this, if you're willing to review and merge it.
Maybe first you can merge or comment on my other PRs that have been waiting for several months: #280 and #312.
When we ran the client towards a http2 server that misbehaved we saw that we got an ever increasing map of unfinished streams (
http2_state.streams
, but alsohttp2_state.stream_refs
). We noticed that the server did not always respond to our requests, even when using a single TLS connection.I have seen that some clients for other languages [1] provides a configuration, a stream idle timeout, which would terminate a stream after not receiving any data or response within configured time.
Would it make sense to have a feature like this in Gun or is it up to the user to make sure that non-finished streams are cancelled/terminated using own timeouts? What is your view on this?
Could it make sense to add some guidance in https://ninenines.eu/docs/en/gun/2.0/guide/http/#_processing_responses
that
gun:cancel/2
could be used to terminate a stream that has not yet received any response or a message with the atomfin
. WDYT?[1] https://nodejs.org/dist//v9.0.0/docs/api/http2.html#http2_http2stream_settimeout_msecs_callback https://eclipse.dev/jetty/javadoc/jetty-12/org/eclipse/jetty/http2/client/HTTP2Client.html#setStreamIdleTimeout(long)