spelling: 'a' vs 'an'

Closes #17487

docs/internals/CLIENT-READERS.md

@@ -128,5 +128,8 @@ By adding the client reader interface, any protocol can control how/if it wants
 The protocols on the other hand no longer have to care to package data most efficiently. At any time, should more data be needed, it can be read from the client. This is used when sending HTTP requests headers to add as much request body data to the initial sending as there is room for.
 
 Future enhancements based on the client readers:
-* `expect-100` handling: place that into a HTTP specific reader at `CURL_CR_PROTOCOL` and eliminate the checks in the generic transfer parts.
-* `eos forwarding`: transfer should forward an `eos` flag to the connection filters. Filters like HTTP/2 and HTTP/3 can make use of that, terminating streams early. This would also eliminate length checks in stream handling.
+* `expect-100` handling: place that into an HTTP specific reader at
+  `CURL_CR_PROTOCOL` and eliminate the checks in the generic transfer parts.
+* `eos forwarding`: transfer should forward an `eos` flag to the connection
+  filters. Filters like HTTP/2 and HTTP/3 can make use of that, terminating
+  streams early. This would also eliminate length checks in stream handling.

docs/internals/CONNECTION-FILTERS.md

@@ -21,7 +21,7 @@ The most important feat of connection filters is that they can be stacked on
 top of each other (or "chained" if you prefer that metaphor). In the common
 scenario that you want to retrieve a `https:` URL with curl, you need 2 basic
 things to send the request and get the response: a TCP connection, represented
-by a `socket` and a SSL instance en- and decrypt over that socket. You write
+by a `socket` and an SSL instance en- and decrypt over that socket. You write
 your request to the SSL instance, which encrypts and writes that data to the
 socket, which then sends the bytes over the network.