You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 also http2_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?
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.
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)
The text was updated successfully, but these errors were encountered: