@@ -1,12 +1,19 @@
 // Copyright (c) .NET Foundation. All rights reserved.
 // Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.
 
+using System;
 using Microsoft.AspNetCore.Server.Kestrel.Filter;
 
 namespace Microsoft.AspNetCore.Server.Kestrel
 {
     public interface IKestrelServerInformation
     {
+        TimeSpan ExecutionTimeout { get; set; }
+
+        TimeSpan HeadersCompleteTimeout { get; set; }
+
+        TimeSpan KeepAliveTimeout { get; set; }
+
         int ThreadCount { get; set; }
 
         bool NoDelay { get; set; }
// Copyright (c) .NET Foundation. All rights reserved.
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.

using Microsoft.AspNetCore.Server.Kestrel.Filter;

namespace Microsoft.AspNetCore.Server.Kestrel
{
    public interface IKestrelServerInformation
    {
        int ThreadCount { get; set; }

        bool NoDelay { get; set; }

        /// <summary>
        /// Gets or sets a flag that instructs <seealso cref="KestrelServer"/> whether it is safe to 
        /// reuse the Request and Response <seealso cref="System.IO.Stream"/> objects
        /// for another request after the Response's OnCompleted callback has fired. 
        /// When this is set to true it is not safe to retain references to these streams after this event has fired.
        /// It is false by default.
        /// </summary>
        /// <remarks>
        /// When this is set to true it is not safe to retain references to these streams after this event has fired.
        /// It is false by default.
        /// </remarks>
        bool ReuseStreams { get; set; }

        IConnectionFilter ConnectionFilter { get; set; }
    }
}

KeepAlive and HeadersComplete are reasonable, but I don't think we need or want ExecutionTimeout at the server level. A) The same functionality can be provided in app/middleware code. B) The timeout is un-enforceable. You can't force an app to abandon a request, you can only close the socket and trip the token. The RequestAborted CancellationToken is at best a hint. There are no thread aborts like v4. C) There are known scenarios this breaks with long running requests. It's one more setting on the server to hunt down and fiddle with when that happens.