Adds HTTP client timeout setting #2344
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be okay to simply document that only vibe-core currently supports connection timeouts and then use
BTW, what exactly is the intent of this change, to define the
I do not agree with this proposal, it complicates. My thoughts:
If fix will be delayed, but someone wants to add a new driver, then it is better to let him immediately see that he still needs to implement timeouts in order to pass the tests.
Yes, at first I also thought of doing the first, but the second was implemented only. That's right, you can rename it.
Could there be necessary timeout when write too? Maybe it is need to implement read+write timeout on sockets?
For example, some kind of stuck with write buffers at busied system can force more and more new connections to be created and wait endlessly for write to it?
I've opened a PR that addresses by concerns and also introduces a "connect" timeout: #2347
W.r.t. making the timeout a constant on buggy driver implementation vs. emitting a runtime warning - making it a constant would require application developers to make very unobvious compile time switches if they still want to be able to compile against one of those drivers. This would go against the basic idea of providing a uniform API across platforms. We are also talking about a feature that is usually non-critical, and the runtime warning that gets emitted for every connection should also be very noticable.
Agreed about adding a configurable write timeout. Both, read and write timeouts should also be reviewed in terms of their semantics (does the full operation time out, or the time until some data arrives or gets sent).