Commit 5bbdcf3
committed
If you have a timeout on the client AND a timeout on the request, the resulting actual timeout is going to be the shorter of the two. By default HttpClient has a timeout of 100 seconds built in, so that means if someone is expecting to be able to send a request and have it wait longer than 100 seconds, it won't work unless the client is also changed.
So I propose we change the property in RestClientOptions which is then applied to HttpClient to be called MaxTimeout so it is a lot more clear what the connection is? You cannot have a longer timeout for any request unless you change this value.
It might also make sense to set this to a default value of something (maybe 100 seconds to make it clear) rather than leaving it null, so the user of the library will be more aware of how the client timeout and request timeout interact with each other?
The other option would be to always set the timeout in the client to infinite, and then always use a request timeout that is the Max() of either the client timeout or the request one if the request one was provided?1 parent 17a3532 commit 5bbdcf3
2 files changed
+2
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
124 | 124 | | |
125 | 125 | | |
126 | 126 | | |
127 | | - | |
| 127 | + | |
128 | 128 | | |
129 | 129 | | |
130 | 130 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
75 | 75 | | |
76 | 76 | | |
77 | 77 | | |
78 | | - | |
| 78 | + | |
79 | 79 | | |
80 | 80 | | |
81 | 81 | | |
| |||
0 commit comments