Implement configuration support #2186

Tratcher · 2017-11-28T23:44:25Z

This includes the updated design. If you like it then I'll start working on the tests.

Related issues:
#2016 - Config support
#2167 - Default settings
#2166 - UseHttps()
#1290 - Config and code parity
#2188 - Listen on https by default

Major features:

KestrelServerOptions.ConfigureEndpointDefaults sets a callback that will be called for every new endpoint no matter what source.
KestrelServerOptions.ConfigureHttpsDefaults sets a callback that will be called to configured every new Https adapter. This is primarily useful for endpoints config.
KestrelServerOptions.Configure(IConfiguration) creates a builder that reads config and registers endpoints. This includes the .Endpoint method to configure additional settings for individually named endpoints from config.
New ListenOptions.UseHttps extensions to provide code and config functional symmetry, and overloads with configureOptions so you don't have to re-invent cert loading when you want to configure other settings.

Supported configurations:

No config: Listens on http://localhost:5000 and https://localhost:5001 (if a default cert is available)
Configure Urls: Urls can be specified by ASNETCORE_URLS environment variable, Urls command line variable, or Urls top level key in hosting's configuration, or via the UseUrls IWebHostBuilder extension. These can be http or https (if a default cert is available). This may be a semicolon separated list. E.g. "Urls": "http://localhost:5000;http://localhost:5001".
Default cert from config: The default certificate can be replaced from configuration. Call serverOptions.Configure(context.Configuration.GetSection("Kestrel")) to specify the configuration section (this will be added to the metapackage). Then add the following config:

{
  "Kestrel": {
    "Certificates": {
       "Default": {
          "Path": "...",
          "Password": ""
       }
    }
  }
}

Certificates can also be loaded from the machine store by specifying the following parameters instead of Path and Password:

  "Subject": "Test Subject", // Required
  "Store": "My", // StoreName defaults to My
  "Location": "CurrentUser/LocalMachine", // StoreLocation defaults to CurrentUser
  "AllowInvalid": true // defaults to false. Setting this to true allows for self-signed or other non-trusted certificates.

Change defaults in code: ConfigureEndpointDefaults and ConfigureHttpsDefaults can be used to change default settings for ListenOptions and HttpsConnectionAdapterOptions, including overriding the default certificate specified in the prior scenario.

options.ConfigureEndpointDefaults(opt =>
{
    opt.Protocols = HttpProtocols.Http1;
});

options.ConfigureHttpsDefaults(httpsOptions =>
{
    httpsOptions.SslProtocols = SslProtocols.Tls12;
});

Configure endpoints: Named endpoints can be added via configuration with the following format:

  "Kestrel": {
	"Endpoints": {
	   "HTTP": { "Url": "http://*:5000" },
           "HTTPS": {
              "Url": "https://*:5463",
              "Certificate": {
                  "Path": "testCert.pfx",
                  "Password": "testPassword"
              }
          }
    }

Schema details:

The endpoints above are named HTTP and HTTPS. These names are arbitrary but will become useful in the next example. These names are case-insensitive.
The Url parameter is required for each endpoint. The format for this parameter is the same as the top level Urls configuration parameter except that it's limited to a single value.
These endpoints replace those defined in the top level Urls configuration rather than adding to them. Endpoints defined in code via Listen are cumulative with the endpoints defined in this configuration section.
The Certificate section is optional, if not specified then the defaults defined in earlier scenarios will be used. If no defaults are available then the server will throw and fail to start.
The Certificate section supports both the Path&Password and the Subject&Store type of certificates.
Any number of endpoints may be defined in this way so long as they don't cause port conflicts.

serverOptions.Configure(context.Configuration.GetSection("Kestrel")) returns a KestrelConfigurationLoader with an .Endpoint(string name, options => { }) method that can be used to supplement configured endpoint's settings.

  serverOptions.Configure(context.Configuration.GetSection("Kestrel"))
    .Endpoint("HTTPS", opt =>
    {
         opt.ListenOptions.Protocols = HttpProtocols.Http1;
         opt.HttpsOptions.SslProtocols = SslProtocols.Tls12;
    });

The configuration section for each endpoint is a available on the options in the Endpoint method so that custom settings may be read.
Multiple configurations may be loaded by calling serverOptions.Configure(context.Configuration.GetSection("Kestrel")) again with another section. Only the last configuration will be used unless Load is explicitly called on prior instances. The metapackage will not call Load so that it's default configuration section may be replaced.
KestrelConfigurationLoader mirrors the Listen family of APIs from KestrelServerOptions as Endpoint overloads so code and config endpoints may be configured in the same place. These overloads do not use names and only consume default settings from configuration.

halter73 · 2017-11-29T00:44:37Z

src/Kestrel/Internal/ConfigReader.cs

+                var url = endpointConfig["Url"];
+                if (string.IsNullOrEmpty(url))
+                {
+                    // TODO: Log?


Why not throw in this case? I would log at a minimum though.

halter73 · 2017-11-29T00:53:10Z

src/Kestrel/KestrelConfigBuilder.cs

+        {
+            if (Options.ConfigurationBuilder == null)
+            {
+                // The builder has already been built.


When does Build get called twice?

I don't expect a given builder to be called twice, but it is a public API. If it was allowed to run twice you'd get duplicate endpoints and port conflicts.

halter73 · 2017-11-29T00:54:51Z

src/Kestrel/KestrelServerOptionsConfigurationExtensions.cs

+    {
+        public static KestrelConfigBuilder Configure(this KestrelServerOptions options, IConfiguration config)
+        {
+            return new KestrelConfigBuilder(options, config); // Assigns itself to options.ConfigurationBuilder


Why not just create a local variable and assign it to options.ConfigurationBuilder in this method instead? It feels slightly better than assigning a partially constructed object even if it's functionally the same.

I did it this way because Build then un-assigns itself, this way you can see the whole lifecycle in one class. I can change it.

halter73 · 2017-11-29T00:56:25Z

src/Kestrel/Internal/ConfigReader.cs

+                        "Path": "testCert.pfx",
+                        "Password": "testPassword"
+                    }
+                }


Nit: I don't mind the comment, but use single line comments instead.

halter73 · 2017-11-29T00:58:39Z

src/Kestrel/KestrelConfigBuilder.cs

+                    Options.GetHttpsDefaults()(httpsOptions);
+
+                    var certInfo = new CertificateConfig(endpoint.CertConfig);
+                    if (certInfo.IsFileCert)


Are any errors thrown if a file path and a store location are both specified for the same endpoint?

No, I don't want to second guess extraneous data. If we have what we need then there's no reason to fail. Nor do I expect people to mix those two up.

I see no reason not to fail if both a file path and a store location is provided.

What's the logic behind choosing file path over the store location when both are specified? If you don't expect people to mix the two, what's wrong with throwing?

halter73 · 2017-11-29T01:10:04Z

src/Kestrel.Core/KestrelServerOptions.cs

+        /// <summary>
+        /// Used to flow settings for connection adapters and other extensions.
+        /// </summary>
+        public IDictionary<string, object> AdapterData { get; } = new Dictionary<string, object>(0);


Yuck. IFeatureCollection?

A dictionary in sheep's clothing... You prefer the typed keys?

This is pretty gross. How is it used?

@davidfowl It's there to allow extension methods defined by connection adapters in separate assemblies to store data between calls to extension methods.

In this case it is used by KestrelServerOptions.ConfigureHttpsDefaults() to store away a default HttpsConnectionAdapterOptions for later use by ListenOptions.UseHttps() and KestrelConfigBuilder.Build().

@davidfowl You're OK with merging this right, I don't exactly have a better alternative right now.

This looks pretty weird, I'm still catching up with this PR and I'll see if I have any better alternatives for what you guys are trying to do

halter73 · 2017-11-29T01:15:21Z

src/Kestrel.Https/KestrelServerOptionsHttpsExtensions.cs

+{
+    public static class KestrelServerOptionsHttpsExtensions
+    {
+        public static void ConfigureHttpsDefaults(this KestrelServerOptions serverOptions, Action<HttpsConnectionAdapterOptions> configureOptions)


I would add doc comments to this and ConfigureEndpointDefaults need to be called prior to the Configure/Listen calls it is providing default values for.

davidfowl · 2017-11-29T05:54:21Z

samples/SampleApp/SampleApp.csproj

    <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="$(MicrosoftExtensionsLoggingConsolePackageVersion)" />
  </ItemGroup>

  <ItemGroup>
    <Content Include="../../test/shared/TestCertificates/testCert.pfx" CopyToOutputDirectory="PreserveNewest" />
  </ItemGroup>

+  <ItemGroup>
+    <Content Update="appsettings.Development.json">
+      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>


nit: Make these properties

I'd rather not hand customizes VS generated settings.

davidfowl · 2017-11-29T05:54:55Z

samples/SampleApp/Startup.cs

                    });

                    options.ListenAnyIP(basePort + 3);

+                    options.ListenAnyIP(basePort + 4, listenOptions =>
+                    {
+                        listenOptions.UseHttps(StoreName.My, "aspnet.test", StoreLocation.CurrentUser);


Will this explode?

If the cert is missing? Yes

davidfowl · 2017-11-29T05:55:57Z

src/Kestrel.Core/KestrelServerOptions.cs

+        /// Provides a configuration source where endpoints will be loaded from on server start.
+        /// The default is null.
+        /// </summary>
+        public IKestrelConfigBuilder ConfigurationBuilder { get; set; }


nit: IKestrelConfigurationBuilder

Tratcher · 2017-12-12T00:29:23Z

@halter73 Updated with tests and ready to review. Let me know if you want me to trim down the new sample content.

Tratcher · 2017-12-12T17:54:13Z

Filed https://github.com/aspnet/KestrelHttpServer/issues/2216 to consider what other settings would make sense to read from config. These would all be easy to add on top of the existing design.

Tratcher · 2017-12-15T21:34:40Z

Poke please review this today.

halter73 · 2017-12-16T00:16:30Z

KestrelHttpServer.sln

@@ -104,6 +104,7 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Protocols.Abstractions", "s
 EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "build", "build", "{C2910A13-B2C2-46D8-81D8-7E166F4F5981}"
 	ProjectSection(SolutionItems) = preProject
+		build\dependencies.props = build\dependencies.props


halter73 · 2017-12-16T00:22:34Z

src/Kestrel/KestrelServerOptionsConfigurationExtensions.cs

+        /// <returns></returns>
+        public static KestrelConfigurationBuilder Configure(this KestrelServerOptions options)
+        {
+            var builder = new KestrelConfigurationBuilder(options, new ConfigurationBuilder().Build());


There's no Configuration.Empty or similar?

Not that I see. @HaoK ?

I'm not concerned about it, this Configure method is only called once or twice at startup.

halter73 · 2017-12-16T00:24:23Z

src/Kestrel/KestrelServerOptionsConfigurationExtensions.cs

+        /// Creates a configuration builder for setting up Kestrel.
+        /// </summary>
+        /// <param name="options"></param>
+        /// <returns></returns>


Nit: remove empty doc comment sections.

halter73 · 2017-12-16T00:27:12Z

samples/SampleApp/Startup.cs

+                {
+                    var env = hostingContext.HostingEnvironment;
+                    config.AddJsonFile("appsettings.json", optional: true)
+                          .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);


At least one of these appsettings files is required now, right?

No, they're optional in the sample. The config is additive on top of the endpoints defined in code.

halter73 · 2017-12-16T00:35:50Z

src/Kestrel.Core/Internal/AddressBinder.cs

+                options.KestrelServerOptions = context.ServerOptions;
+                context.ServerOptions.EndpointDefaults(options);
+
+                if (!options.ConnectionAdapters.Any(f => f.IsHttps))


So if you don't configure a specific endpoint and the DefaultAddressStrategy is used, you bind to "http://localhost:5000" and "https://localhost:5001". So far so good.

But if you also configure an HTTPS adapter using ConfigureEndpointDefaults you now listen on "https://localhost:5000" and don't listen on port 5001 at all? Seems weird.

If you add HTTPS in ConfigureEndpointDefaults then you end up listening on both "https://localhost:5000" and "https://localhost:5001". This if only skips adding the https adapter twice, it doesn't skip binding to this endpoint.

halter73 · 2017-12-16T01:07:24Z

src/Kestrel.Core/Internal/IDefaultHttpsProvider.cs

+        /// <summary>
+        /// Returns the default certificate, if available, otherwise null.
+        /// </summary>
+        X509Certificate2 Certificate { get; }


When does this need to be set?

You found it over at https://github.com/aspnet/KestrelHttpServer/pull/2186/files#diff-590565eed2ca0d80acae41edb7fde1a7R230. Continuing the discussion there.

halter73 · 2017-12-16T01:08:17Z

src/Kestrel.Core/KestrelServerOptions.cs

+        /// <param name="configureOptions"></param>
+        public void ConfigureEndpointDefaults(Action<ListenOptions> configureOptions)
+        {
+            EndpointDefaults = configureOptions ?? throw new ArgumentNullException(nameof(configureOptions));


Should we allow this to stack? Either way the doc comments should mention whether this overrides previous calls to ConfigureEndpointDefaults.

I don't think more that one default action is required. Comments updated.

halter73 · 2017-12-16T01:14:02Z

src/Kestrel.Https/Internal/CertificateLoader.cs

+                    }
+
+                    DisposeCertificates(storeCertificates);
+                    DisposeCertificates(foundCertificates);


After you're done with a X509Store, you seriously have to enumerate X509Store.Certificates and dispose all the ones you didn't use? That's ridiculous if true.

Also isn't everything in foundCertificates also in storeCertificates, so the second call is just double disposing?

@javiercn? You've played with the cert store a lot lately.

Note this was copied from Hosting with an added EKU check.
https://github.com/aspnet/Hosting/blob/a2962d54f18dece7ec57ee42f3e565f3727168e1/shared/Microsoft.AspNetCore.Certificates.Configuration.Sources/CertificateStoreLoader.cs#L50

I think you're right about the double dispose, unless Find is making a deep copy for some reason.

@halter73 I think you need to dispose the ones that you don't use. I would have to ask, but I believe that when you open the store and enumerate the certificates you get some unmanaged references to the actual underlying keys (when present) so I believe you need to dispose those.

I believe that the dotnet crypto folks gave us explicit feedback on Cesar's original PR about this. We can probably dig up that PR

Native resources would all have finalizers, but it's a good habit to explicitly dispose them when you're done.

halter73 · 2017-12-16T01:19:02Z

src/Kestrel/EndpointConfiguration.cs

+        }
+
+        public bool IsHttps { get; }
+        public ListenOptions Listener { get; }


Nit: name it ListenOptions.

halter73 · 2017-12-16T01:23:08Z

src/Kestrel/KestrelConfigurationBuilder.cs

+
+        /// <summary>
+        /// Bind to given IP address and port.
+        /// The callback configures endpoint-specific settings.


Nit: If we're going to include the sentence about the configure callback, we should do so for all applicable overloads.

HaoK · 2017-12-16T05:48:29Z

samples/SampleApp/Startup.cs

+                        .Configure()
+                        .Endpoint(IPAddress.Loopback, basePort + 5)
+                        .LocalhostEndpoint(basePort + 6)
+                        .Build();


So, this I'm guessing Build() is required because that's what triggers the endpoint to actually get added to the options?

Related question, there is no Build() on the Kestrel config section binding one below, so would that just basically be a no-op giving you an unused builder?

I think it might make things simpler if you just add a separate dedicated options for the defaults, i.e. KestralServerDefaultOptions and configure it via options normally. Thent he ConfigureXyzDefault methods would just be configuring this other option instead of manipulating the builder.

You'd still need the existing builder logic to be able to create endpoints from config, but its no longer part of the KestralServerOptions. The server can just get new default options along with the normal options and continue doing the same thing that Build() does. The only change that might be required is all of the defaults configuration would need to be done earlier, as they would need to be in the service container.

I definitely don't have a ton of context in this code or how everything fits together, but using a dedicated options class for the defaults seems to be an potential alternative path to consider

Kestrel calls Build on the last builder at Start. The idea is that the metapackage will assign a default configuration but it won't call Build so that that default can be replaced by user code. If you want to add two configurations you need to call Build on at least the first one.

instead of manipulating the builder.
? The ConfigureXDefault methods don't manipulate the builder.

We didn't want to go the route of KestralServerDefaultOptions as that would require duplicating every setting. With the callbacks all settings added to ListenOptions are automatically available as defaults. There are also some things like the connection adapters that are better to create per endpoint.

Requiring them to call build sometimes seems a bit awkward, can't you just expose a list that they can control and remove/add as needed instead... options.Builders.Add instead of options.Configure

RE duplication, you should be able to reuse whatever sub options you want in the defaults, why wouldn't you be able to use the ListenOptions/Adapters for the default options as well. But even if you wanted to have a complete identical surface area, you could just use named options

// Store defaults via "default" name

var defaults = IOptionsMonitor<KestrelServerOptions>.Get("defaults"); // ConfigureXDefault methods just pass extra name parameter

In practice I expect them to almost never call build, they either use the config defined in the metapackage or they use the one from their own code. Keeping a list does not seem necessary. We'll see what the preview1 feedback is like.

From your examples I'm not sure you understand what defaults we're talking about configuring. It's not that there are multiple KestrelServerOptions with a set of defaults, it's that a given KestrelServerOptions has multiple endpoints / ListenOptions / httpsOptions and you can define defaults for the options on those. The connection adapters are the most tricky here, you'd need to create a fresh one for each endpoint so you can't create one as a default without implementing some kind of cloning logic. With the current model you can re-use all of the extensions off of ListenOptions for creating connection adapters.

So let me try to get on the same page...

So the KestrelServer eventually wants to produce a bunch of endpoints which has options in a ListenOptions instance, (Endpoints are created from these 1:1?)

Https is doing weird stuff which I guess relates to the fact that its configuring listen option instances and doing its own options like stuff. The EndpointDefaults action is basically equivalent to doing a ConfigureAll on ListenOptions if you were using IOptions.

Part of the confusion here I think is that KestrelServerOptions are using IOptions/Configure, while there are a few options types that are used more like EndpointSettings/AdapterSettings and not configured like normal options.

With named endpoints, that matches exactly named options, you can just use IOptions<EndpointOptions>.Get(name) and just bind against config.GetSection("Kestrel:Endpoints"). Your defaults could then just be sugar for services.ConfigureAll(o => o.Protocols = HttpProtocols.Http1)

Assuming you can just hang all Endpoint operations off of .Endpoints, maybe something like? But I'm sure I don't grok what's going on around the adapter/https yet.

UseKestrel(context, o => { // Default wireup (but showing what the sugar methods call) o.ConfigureAll<EndpointOptions>(opt => opt.Protocols = HttpProtocols.Http1); o.ConfigureAll<HttpsDefaultOptions>(o => o.SslProtocols = SslProtocols.Tls12); // just binds all the endpoint options to their names using Configure (and defaults?) o.Endpoints.Configure(context.Configuration.GetSection("Kestrel:Endpoints")); o.Endpoints.Add(IPAddress.Loopback, basePort + 5); o.Endpoints.AddLocalhost(basePort + 6); o.Endpoints.AddNamed("NamedEndpoint", opt => { opt.Listener.Protocols = HttpProtocols.Http1; }) o.Endpoints.AddNamed("NamedHttpsEndpoint", opt => { opt.Https.SslProtocols = SslProtocols.Tls12; }); }

You're still missing quite a bit of context. Stop by if you want to walk through it.

The question I'd originally sent you was if configuration has a static helper for the scenario where I only want an empty placeholder instance like new ConfigurationBuilder().Build()

No because there's always config, its pretty strange to pass in empty configuration to a configuration loader class though... Hence why I think the naming is a bit weird.

Like this doesn't use config at all right?

options .Configure() .Endpoint(IPAddress.Loopback, basePort + 5) .LocalhostEndpoint(basePort + 6) .Load();

Damian wanted to mirror the Listen APIs so you could still configure everything in one place. Yes it makes for a slightly odd fraken type.

That's fine, my main point is that this seems more than just a configuration loader, this is public endpoint management API basically, where the ctor takes an optional config and Load() is basically committing the set of endpoints.

I think building that dedicated API where configuration is just one way to import a chunk of endpoint settings is maybe a simpler way to expose this...

I still think this would be easier to understand if the API just exposed the endpoints on the options. Having to call configure/endpoint/load and then another configure/endpoint block just seems strange.

Seems like it'd be better to let them express it more concisely, without any weird loads.

options .LoadConfig(context.Configuration.GetSection("Kestrel") // Order for this shouldn't matter when its called, it just adds bindings using the config section for named endpoints .AddEndpoint(IPAddress.Loopback, basePort + 5) // uses defaults .AddLocalhostEndpoint(basePort + 6) // uses defaults .AddEndpoint("NamedEndpoint", opt => // uses defaults and config section bindings via name { opt.ListenOptions.Protocols = HttpProtocols.Http1; }) .AddEndpoint("NamedHttpsEndpoint", opt => // uses defaults and config section bindings via name { opt.HttpsOptions.SslProtocols = SslProtocols.Tls12; }

And you can always just let them Remove/Update existing endpoints.

HaoK · 2017-12-16T05:57:42Z

src/Kestrel/Internal/ConfigurationReader.cs

+
+        public IConfigurationSection ConfigSection { get; }
+
+        public bool Exists => ConfigSection.GetChildren().Any();


Nit: you could consider using the Exists extension method which is similar.
https://github.com/aspnet/Configuration/blob/dev/src/Config.Abstractions/ConfigurationExtensions.cs#L76

You can consider using section.Bind(this) if you wanted to avoid all the ConfigSection property lookups where the name is the property name.

HaoK · 2017-12-16T06:05:36Z

src/Kestrel/Internal/ConfigurationReader.cs

+
+namespace Microsoft.AspNetCore.Server.Kestrel.Core.Internal
+{
+    internal class ConfigurationReader


Nit: you could consider just making this into two internal static extension methods on IConfiguration

IConfiguration.ReadCertificates(this IConfiguration)
IConfiguration.ReadEndpoints(this IConfiguration)

No need when this is only for internal usage.

Tratcher · 2017-12-18T20:22:46Z

Note many of the strange design decisions here are due to the assembly separation between K.Core and K.Https. We've opted to merge the https libraries into core and then revisit this PR.

Tratcher · 2017-12-19T13:43:27Z

Rebased on the new merged assemblies and code consolidated. Ready for a final pass @halter73

muratg · 2017-12-19T19:53:08Z

src/Kestrel.Core/KestrelConfigurationLoader.cs

+        /// <summary>
+        /// Open a socket file descriptor.
+        /// </summary>
+        public KestrelConfigurationLoader HandleEndpoint(ulong handle) => HandleEndpoint(handle, _ => { });


Just curious - did we expose ulongs in the public API before?

Yes these are all mirrors of the existing Listen APIs.

Yes. KestrelServerOptions.ListenHandle(ulong).

halter73

I would like a test for force upgrading an HTTP endpoint passed in via the IServerAddressesFeature to HTTPS though.

guardrex · 2018-04-27T00:32:08Z

@Tratcher

In the initial post above Certificates is a child of Kestrel ...

{
  "Kestrel": {
    "Certificates": {
       "Default": {
          "Path": "...",
          "Password": ""
       }
    }
  }
}

... but in the blog post, it's not ...

https://blogs.msdn.microsoft.com/webdev/2018/02/02/asp-net-core-2-1-roadmap#security

{
  "Kestrel": {
    
  },
  "Certificates": {
    "Default": {
      "Path": "<file>",
      "Password": "<password>"
    },

    "Default": {
      "Subject": "",
      "Store": "",
      "Location": "",
      "AllowInvalid": ""
    }
  }
}

... no love from schema store ... http://json.schemastore.org/appsettings

I assume the blog post is incorrect. cc/ @danroth27

Tratcher · 2018-04-27T04:40:16Z

@guardrex you're correct. We've already fixed that in another blog post, but it looks like we should update this one too. I left him a comment directly on the that post.

Tratcher added this to the 2.1.0-preview1 milestone Nov 28, 2017

Tratcher self-assigned this Nov 28, 2017

Tratcher requested review from halter73 and davidfowl November 28, 2017 23:44

halter73 reviewed Nov 29, 2017

View reviewed changes

davidfowl reviewed Nov 29, 2017

View reviewed changes

Tratcher force-pushed the tratcher/config branch from 37b20c2 to c599d2a Compare December 5, 2017 21:03

danroth27 mentioned this pull request Dec 8, 2017

HTTPS binding configuration for Kestrel #2016

Closed

danroth27 added the https label Dec 8, 2017

Tratcher force-pushed the tratcher/config branch from dc7515b to 2b21b63 Compare December 12, 2017 00:27

Tratcher changed the title ~~[WIP] Implement configuration support~~ Implement configuration support Dec 12, 2017

Tratcher requested a review from pakrym December 12, 2017 23:33

halter73 reviewed Dec 16, 2017

View reviewed changes

HaoK reviewed Dec 16, 2017

View reviewed changes

Tratcher mentioned this pull request Dec 18, 2017

Merge Kestrel.Https into Kestrel.Core #2224

Merged

Tratcher force-pushed the tratcher/config branch from 0a1be15 to e1de1d5 Compare December 19, 2017 05:11

muratg reviewed Dec 19, 2017

View reviewed changes

halter73 approved these changes Dec 20, 2017

View reviewed changes

Implement config support #1290 #1879 #2016 #2166 #2167 #2188

dfaf37c

Tratcher force-pushed the tratcher/config branch from 9b86b3c to dfaf37c Compare December 21, 2017 17:31

Tratcher merged commit dfaf37c into dev Dec 21, 2017

Tratcher deleted the tratcher/config branch December 21, 2017 17:32

This was referenced Dec 21, 2017

New kestrel configuration & related APIs dotnet/AspNetCore.Docs#5056

Closed

Allow untrusted certs in tests aspnet/MetaPackages#249

Merged

Add kestrel config to CreateDefaultBuilder aspnet/MetaPackages#250

Merged

Tratcher mentioned this pull request Apr 16, 2018

Have you broken Kestrel configuration? #1442 #2495

Closed

guardrex mentioned this pull request Apr 27, 2018

New kestrel configuration & related APIs dotnet/AspNetCore.Docs#6102

Merged

natemcmaster mentioned this pull request Dec 13, 2018

Log HTTPs cert info on startup dotnet/aspnetcore#4759

Open

Tratcher mentioned this pull request Dec 13, 2018

Read additional KestrelServerOptions from config dotnet/aspnetcore#4765

Open


		public IConfigurationSection ConfigSection { get; }

		public bool Exists => ConfigSection.GetChildren().Any();

Implement configuration support #2186

Implement configuration support #2186

Uh oh!

Conversation

Tratcher commented Nov 28, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tratcher commented Dec 12, 2017

Uh oh!

Tratcher commented Dec 12, 2017

Uh oh!

Tratcher commented Dec 15, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tratcher Dec 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Tratcher commented Nov 28, 2017 •

edited

Loading

Tratcher Dec 16, 2017 •

edited

Loading

HaoK Dec 16, 2017 •

edited

Loading

Tratcher Dec 16, 2017 •

edited

Loading