-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constrain X509ChainPolicy.UrlRetrievalTimeout to acceptable ranges #40578
Comments
Do these kinds of changes generally need to go throw API review? |
@GrabYourPitchforks Do you have thoughts here? The "compat, compat everywhere" voice in my head says that we should just unify that negative numbers mean one minute. But as an API designer I agree that an ArgumentOutOfRangeException in the setter is what the original implementation should have had. One possible answer is to wait another week and change it as the first break for 6; though I handwavily feel that it's better to break it in 5 than 6-preview. |
It's technically the max of whatever that version of Windows is willing to tolerate. I have no idea if the cap is say, 5 minutes on Windows 7 / 8, then negative number corresponds to 5 minutes. |
The
X509ChainPolicy.UrlRetrievalTimeout
property is aTimeSpan
that currently does not throw when given a value less than zero, orTotalMilliseconds
larger thanint.MaxValue
. A negative value for this property behaves differently from Linux and Windows. Linux treats a negative value as-is and every network operation during chain building will time out (all time-budget has been used). Windows ends up treating the negative value as an unsigned value, so -1 ends up being treated asuint.MaxValue
for example. However, Win32 appears to cap the value at 1 minute anyway, so all negative values are currently being treated as 1 minute.I propose that the
set
forUrlRetrievalTimeout
throw anArgumentOutOfRangeException
if it is less than zero or greater thanTimeSpan.FromMilliseconds(int.MaxValue)
. Using a negative value likely isn't intentional and more likely aDateTime
arithmetic mistake or a typo. Using a large value likeTimeSpan.MaxValue
may be done as an attempt to have no timeout.This would be a breaking behavioral change, though a small one in my opinion.
The text was updated successfully, but these errors were encountered: