-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Watch file-based certificates for changes #49979
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
Conversation
When `IConfiguration` specifies certificates by path and `reloadOnChange` is true, monitor those paths for changes and trigger reloads. The reload behavior is the same as if the path in the configuration file were changed, rather than the contents of the referenced file. - Does not apply to code-based configuration, which never triggers reloads - Does not trigger on deletion - that would just tear down the server - Does not look through symlinks to determine whether the target has changed - On by default (when `reloadOnChange` is true) but can be disabled with app context switch `Microsoft.AspNetCore.Server.Kestrel.DisableCertificateFileWatching` Fixes dotnet#32351
|
I still have to write tests for the |
|
Obviously, the scariest part is the locking (esp when events arrive during reload), so I'd appreciate some eyes on that. The biggest problem I'm aware of is that a flood of file changes (how many certs are you watching anyway?) could prolong reload, since there's no easy way to specify that it should have priority in the lock queue. |
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcher.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcherLoggerExtensions.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcher.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcher.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcherLoggerExtensions.cs
Outdated
Show resolved
Hide resolved
|
I have to admit I'm surprised all the CI failures are on Windows. I suspect they just need to wait longer for the FS events. Edit: doubling the timeout to 10 seconds didn't help (odd that exactly the same tests should fail) and I can't repro locally. I've speculatively modified the way I'm Edit 2: I have a repro (of a related, but different test) on a helix VM, so I should at least be able to investigate. |
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcherLoggerExtensions.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Core/src/Internal/CertificatePathWatcherLoggerExtensions.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Kestrel/test/KestrelConfigurationLoaderTests.cs
Outdated
Show resolved
Hide resolved
…system to make testing more reliable
halter73
left a comment
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.
Looks good. I like how you used CertificateConfig.FileHasChanged so the right endpoints get restarted.
When
IConfigurationspecifies certificates by path andreloadOnChangeis true, monitor those paths for changes and trigger reloads. The reload behavior is the same as if the path in the configuration file were changed, rather than the contents of the referenced file.reloadOnChangeis true) but can be disabled with app context switchMicrosoft.AspNetCore.Server.Kestrel.DisableCertificateFileWatchingFixes #32351