feat(client): allow to set response timeout per request#1170
Conversation
|
IMO API like this is confusing to users who don't know the low level of connection well. It may not result in a behavior they desire due to how connection pool work. There seems no real usage where you need a scoped timeout rather than request/response timeout. The connect and handshake timeout are there for eventual file descriptor recycle to avoid keep hogging system resources and the slowest connection you make determines the value of it. Shrinking/prolonging the duration does not make a difference. |
|
Main goal was to reuse the same client for different host with different connect timeout, but we can always use different client in this case you are right. Then i can reduce the timeout config to only request / response ? ATM, on main, it's only request, response timeout depend on the client. EDIT : changed to only request / response timeout per request builder |
60e8190 to
7ffede1
Compare
8a8c0d4 to
63e8346
Compare
63e8346 to
94ec4c0
Compare
94ec4c0 to
3b3af27
Compare
3b3af27 to
d743376
Compare
This allow configuring all timeout options per request instead of having only the request timeout set (obviously connect / tls timeout may not be used each time will depend on the pool)
EDIT : PR changed to only specifying request / response timeout instead of all possible one