Clarify request draining comments (#18132)

* Clarify request draining comments

* Nits

Co-authored-by: Luke Latham <1622880+guardrex@users.noreply.github.com>

Author: Tratcher

aspnetcore/fundamentals/servers/kestrel.md

@@ -5,7 +5,7 @@ description: Learn about Kestrel, the cross-platform web server for ASP.NET Core
 monikerRange: '>= aspnetcore-2.1'
 ms.author: riande
 ms.custom: mvc
-ms.date: 05/03/2020
+ms.date: 05/04/2020
 no-loc: [Blazor, "Identity", "Let's Encrypt", Razor, SignalR]
 uid: fundamentals/servers/kestrel
 ---
@@ -2708,33 +2708,35 @@ Host Filtering Middleware is disabled by default. To enable the middleware, defi
 
 ::: moniker-end
 
-## HTTP connection request draining
+## HTTP/1.1 request draining
 
-Opening HTTP connections is relatively demanding on server resources, so Kestrel tries to reuse connections. A request must be fully consumed to be reused. Some requests can't be fully consumed, such as a `POST` requests where the server returns a redirect. In the `POST`-redirect case:
+Opening HTTP connections is time consuming. For HTTPS, it's also resource intensive. Therefore, Kestrel tries to reuse connections per the HTTP/1.1 protocol. A request body must be fully consumed to allow the connection to be reused. The app doesn't always consume the request body, such as a `POST` requests where the server returns a redirect or 404 response. In the `POST`-redirect case:
 
 * The client may already have sent part of the `POST` data.
 * The server writes the 301 response.
-* The connection can't be used for a new request because the `POST` data from the previous request hasn't been fully read.
-* Kestrel tries to drain the request. Draining the request means reading and discarding the data waiting to be read without processing the data.
+* The connection can't be used for a new request until the `POST` data from the previous request body has been fully read.
+* Kestrel tries to drain the request body. Draining the request body means reading and discarding the data without processing it.
 
-The draining process makes a tradoff between allowing remaining data to be read/discarded and closing the connection without reading remaining data:
+The draining process makes a tradoff between allowing the connection to be reused and the time it takes to drain any remaining data:
 
 * Draining has a timeout of five seconds, which isn't configurable.
-* If all of the data specified by the `Content-Length` header hasn't been read before reaching the timeout, the connection is closed.
+* If all of the data specified by the `Content-Length` or `Transfer-Encoding` header hasn't been read before the timeout, the connection is closed.
 
 Sometimes you may want to terminate the request immediately, before or after writing the response. For example, clients may have restrictive data caps, so limiting uploaded data might be a priority. In such cases to terminate a request, call [HttpContext.Abort](xref:Microsoft.AspNetCore.Http.HttpContext.Abort%2A) from a controller, Razor Page, or middleware.
 
 There are caveats to calling `Abort`:
 
-* It's demanding on server resources to close and open TCP connections.
+* Creating new connections can be slow and expensive.
 * There's no guarantee that the client has read the response before the connection closes.
-* Calling `Abort` should be rare and reserved for server error cases, not common errors.
+* Calling `Abort` should be rare and reserved for severe error cases, not common errors.
   * Only call `Abort` when a specific problem needs to be solved. For example, call `Abort` if malicious clients are trying to `POST` data or when there's a bug in client code that causes large or numerous requests.
-  * Don't call `Abort` to process ordinary resonses, such as HTTP 404 (Not Found).
+  * Don't call `Abort` for common error situations, such as HTTP 404 (Not Found).
 
-Calling [HttpResponse.CompleteAsync](xref:Microsoft.AspNetCore.Http.HttpResponse.CompleteAsync%2A) before calling `Abort` ensures that the response has left the server. However, client behavior isn't predictable and can't be directly controlled by the app. Clients may continue to send data after calling `CompleteAsync` and `Abort`.
+Calling [HttpResponse.CompleteAsync](xref:Microsoft.AspNetCore.Http.HttpResponse.CompleteAsync%2A) before calling `Abort` ensures that the server has completed writing the response. However, client behavior isn't predictable and they may not read the response before the connection is aborted.
 
-If possible, it's better for clients to utilize the [Expect: 100-continue](https://developer.mozilla.org/docs/Web/HTTP/Status/100) request header so that they wait for the server to respond before starting to send the request body.
+This process is different for HTTP/2 because the protocol supports aborting individual request streams without closing the connection. The five second drain timeout doesn't apply. If there's any unread request body data after completing a response, then the server sends an HTTP/2 RST frame. Additional request body data frames are ignored.
+
+If possible, it's better for clients to utilize the [Expect: 100-continue](https://developer.mozilla.org/docs/Web/HTTP/Status/100) request header and wait for the server to respond before starting to send the request body. That gives the client an opportunity to examine the response and abort before sending unneeded data.
 
 ## Additional resources