tidy-up: fix typos in docs and comments

Correct grammar and spelling in documentation and source comments. Also
fix the Aspell configuration key and one user-facing OpenSSL error
message.

Closes #22647

.github/scripts/pyspelling.yaml

@@ -7,8 +7,8 @@
 matrix:
   - name: Markdown
     expect_match: false
-    apsell:
-      mode: en
+    aspell:
+      lang: en
     dictionary:
       wordlists:
         - wordlist.txt

docs/EARLY-RELEASE.md

@@ -57,7 +57,7 @@ the three ones above are all 'no'.
 - Can the bug be fixed "easily" by applying a patch?
 - Does the bug break the build? Most users do not build curl themselves.
 - How long is it until the already scheduled next release?
-- Can affected users safely rather revert to a former release until the next
+- Can affected users safely revert to a former release until the next
   scheduled release?
 - Is it a performance regression with no functionality side-effects? If so it
   has to be substantial.

docs/TODO.md

@@ -702,10 +702,10 @@ RFC 6266 documents how UTF-8 names can be passed to a client in the
 
 [curl issue 1888](https://github.com/curl/curl/issues/1888)
 
-## Option to make `-Z` merge lined based outputs on stdout
+## Option to make `-Z` merge line-based outputs on stdout
 
-When a user requests multiple lined based files using `-Z` and sends them to
-stdout, curl does not *merge* and send complete lines fine but may send
+When a user requests multiple line-based files using `-Z` and sends them to
+stdout, curl does not *merge* and send complete lines but may send
 partial lines from several sources.
 
 [curl issue 5175](https://github.com/curl/curl/issues/5175)

docs/cmdline-opts/_URL.md

@@ -20,5 +20,5 @@ setup handshakes. This improves speed. Connection reuse can only be done for
 URLs specified for a single command line invocation and cannot be performed
 between separate curl runs.
 
-Everything provided on the command line that is not a command line option or
-its argument, curl assumes is a URL and treats it as such.
+curl assumes everything provided on the command line that is not a command
+line option or its argument is a URL and treats it as such.

docs/internals/MULTI-EV.md

@@ -55,11 +55,11 @@ compared to the *previous* pollset. If relevant changes are detected,
  * a socket was also in the previous one, but IN/OUT flags changed
  * a socket in the previous one is no longer part of the current
 
-`multi_ev.c` keeps a `struct mev_sh_entry` for each sockets in a hash
+`multi_ev.c` keeps a `struct mev_sh_entry` for each socket in a hash
 with the socket as key. It tracks in each entry which transfers are
-interested in this particular socket. How many transfer want to read
-and/or write and what the summarized `POLLIN/POLLOUT` action, that
-had been reported to `multi->socket_cb` was.
+interested in this particular socket, how many transfers want to read
+and/or write and the summarized `POLLIN/POLLOUT` action reported to
+`multi->socket_cb`.
 
 This is necessary as a socket may be in use by several transfers
 at the same time (think HTTP/2 on the same connection). When a transfer

docs/internals/THRDPOOL-AND-QUEUE.md

@@ -57,12 +57,12 @@ A thread pool can be destroyed via `Curl_thrdpool_destroy(pool, join)` where
 
 ### Safety
 
-The thread pool operates use a mutex and condition variables to manage
+The thread pool operates using a mutex and condition variables to manage
 concurrency. All interactions and callback invocation are done under
 the pool's mutex lock, *except* the "process" callback which is invoked
 unlocked.
 
-To avoid deadlocks, no callback must invoked other pool functions. Also,
+To avoid deadlocks, no callback must invoke other pool functions. Also,
 any call of pool functions may result in callback invocations.
 
 The "work items", once "taken" by the pool, should not be referenced
@@ -102,7 +102,7 @@ the queue. Calling `Curl_thrdq_recv()` delivers processed items back.
 
 ### Safety
 
-The thread queue operates use a mutex and condition variables to manage
+The thread queue operates using a mutex and condition variables to manage
 concurrency. All interactions and callback invocation are done under
 the queue's mutex lock, *except* the "process" callback which is invoked
 unlocked.

docs/internals/TIME-KEEPING.md

@@ -25,7 +25,7 @@ this was mostly not noticeable. On slow machines or in CI, this led to rare
 and annoying test failures.
 
 (Especially when we added assertions that the reported "timeline" of a
-transfer was in the correct order: *queue -> nameloopup -> connect ->
+transfer was in the correct order: *queue -> namelookup -> connect ->
 appconnect ->...*.)
 
 ## Revised Approach

docs/libcurl/libcurl-security.md

@@ -54,8 +54,8 @@ stored in a home directory that is NFS mounted or used on another network
 based file system, so the clear text password flies through your network every
 time anyone reads that file.
 
-For applications that enable .netrc use, a user who manage to set the right
-URL might then be possible to pass on passwords.
+For applications that enable .netrc use, a user who manages to set the right
+URL might then make it possible to pass on passwords.
 
 To avoid these problems, do not use .netrc files and never store passwords in
 plain text anywhere.

docs/libcurl/libcurl-url.md

@@ -108,8 +108,8 @@ with it.
 
 # SET PARTS
 
-A user set individual URL parts, either after having parsed a full URL or
-instead of parsing such.
+A user can set individual URL parts, either after having parsed a full URL or
+instead of parsing one.
 
 ~~~c
   rc = curl_url_set(urlp, CURLUPART_FRAGMENT, "anchor", 0);

docs/libcurl/opts/CURLOPT_COOKIE.md

@@ -43,12 +43,12 @@ multiple requests are done due to authentication, followed redirections or
 similar, they all get this cookie passed on.
 
 The cookies set by this option are separate from the internal cookie storage
-held by the cookie engine and they are not be modified by it. If you enable
+held by the cookie engine and they are not modified by it. If you enable
 the cookie engine and either you have imported a cookie of the same name (e.g.
 'foo') or the server has set one, it has no effect on the cookies you set
 here. A request to the server sends both the 'foo' held by the cookie engine
 and the 'foo' held by this option. To set a cookie that is instead held by the
-cookie engine and can be modified by the server use CURLOPT_COOKIELIST(3).
+cookie engine and can be modified by the server, use CURLOPT_COOKIELIST(3).
 
 Since this custom cookie is appended to the Cookie: header in addition to any
 cookies set by the cookie engine, there is a risk that the header ends up too

docs/libcurl/opts/CURLOPT_URL.md

@@ -72,7 +72,7 @@ option.
 
 Using this option multiple times makes the last set string override the
 previous ones. Set it to NULL to disable its use again. Note however that
-libcurl needs a URL set to be able to performed a transfer.
+libcurl needs a URL set to be able to perform a transfer.
 
 The parser used for handling the URL set with CURLOPT_URL(3) is the same that
 curl_url_set(3) uses.

lib/cf-socket.c

@@ -1204,7 +1204,7 @@ static CURLcode cf_socket_open(struct Curl_cfilter *cf,
   ctx->started_at = *Curl_pgrs_now(data);
 #ifdef SOCK_NONBLOCK
   /* Do not tuck SOCK_NONBLOCK into socktype when opensocket callback is set
-   * because we would not know how socketype is about to be used in the
+   * because we would not know how socktype is about to be used in the
    * callback, SOCK_NONBLOCK might get factored out before calling socket().
    */
   if(!data->set.fopensocket)

lib/cw-out.c

@@ -413,7 +413,7 @@ static CURLcode cw_out_do_write(struct cw_out_ctx *ctx,
 
 out:
   if(result) {
-    /* We do not want to invoked client callbacks a second time after
+    /* We do not want to invoke client callbacks a second time after
      * encountering an error. See issue #13337 */
     ctx->errored = TRUE;
     cw_out_bufs_free(ctx);

lib/http.c

@@ -524,7 +524,7 @@ static bool http_should_fail(struct Curl_easy *data, int httpcode)
   /*
    * Examine the current authentication state to see if this is an error. The
    * idea is for this function to get called after processing all the headers
-   * in a response message. If we have been to asked to authenticate
+   * in a response message. If we have been asked to authenticate at
    * a particular stage, and we have done it, we are OK. If we are already
    * completely authenticated, it is not OK to get another 401 or 407.
    *

lib/multihandle.h

@@ -86,7 +86,7 @@ typedef enum {
 
 /* This is the struct known as CURLM on the outside */
 struct Curl_multi {
-  /* First a simple identifier to easier detect if a user mix up
+  /* First a simple identifier to more easily detect if a user mixes up
      this multi handle with an easy handle.
      Set this to CURLMULTI_MAGIC_NUMBER. */
   uint32_t magic;

lib/smtp.c

@@ -1423,8 +1423,8 @@ static CURLcode smtp_state_rcpt_resp(struct Curl_easy *data,
 
   is_smtp_err = (smtpcode / 100 != 2);
 
-  /* If there is multiple RCPT TO to be issued, it is possible to ignore errors
-     and proceed with only the valid addresses. */
+  /* If there are multiple RCPT TO commands to issue, it is possible to
+     ignore errors and proceed with only the valid addresses. */
   is_smtp_blocking_err = (is_smtp_err && !data->set.mail_rcpt_allowfails);
 
   if(is_smtp_err) {

lib/uint-hashset.c

@@ -57,14 +57,14 @@ static const uint8_t u8_smask[] = {
  * - We have an array: (id, string) are ideally placed at index "id % size".
  * - If slot at index is already occupied, we have a collision.
  * - A simple collision strategy would look at the next index, and the
- *   next until until finding an empty slot.
+ *   next until finding an empty slot.
  * - The drawback is that this may lead to many checks on lookups, as it
  *   will need to also look at subsequent slots until it finds the match.
  *   The amount of lookups is the "probe sequence length" (psl) and this
  *   may vary greatly between entries.
  * - Robin Hood Hashing balances the 'psl's of all entries more evenly:
  *   - psl == 0 means an entry is in exactly the right slot
- *   - pasl == 1 means it is in the slot right after. psl == 2 is the slot
+ *   - psl == 1 means it is in the slot right after. psl == 2 is the slot
  *     after that, etc.
  *   - when inserting a new entry, track its psl. Finding a slot where
  *     the existing entry has a lower psl makes a swap. Put the new entry

lib/urlapi.c

@@ -1699,7 +1699,7 @@ CURLUcode curl_url_get(const CURLU *u, CURLUPart what,
     ifmissing = CURLUE_NO_QUERY;
     plusdecode = flags & CURLU_URLDECODE;
     if(ptr && !ptr[0] && !(flags & CURLU_GET_EMPTY))
-      /* there was a blank query and the user do not ask for it */
+      /* there was a blank query and the user does not ask for it */
       ptr = NULL;
     break;
   case CURLUPART_FRAGMENT:

lib/urldata.h

@@ -1157,8 +1157,8 @@ typedef void multi_sub_xfer_done_cb(struct Curl_easy *data,
  */
 
 struct Curl_easy {
-  /* First a simple identifier to easier detect if a user mix up this easy
-     handle with a multi handle. Set this to CURLEASY_MAGIC_NUMBER */
+  /* First a simple identifier to more easily detect if a user mixes up this
+     easy handle with a multi handle. Set this to CURLEASY_MAGIC_NUMBER */
   uint32_t magic;
   /* once an easy handle is added to a multi, either explicitly by the
    * libcurl application or implicitly during `curl_easy_perform()`,

lib/vauth/digest.c

@@ -179,7 +179,7 @@ static char *auth_digest_string_quoted(const char *s)
 }
 
 /* Retrieves the value for a corresponding key from the challenge string
- * returns TRUE if the key could be found, FALSE if it does not exists
+ * returns TRUE if the key could be found, FALSE if it does not exist
  */
 static bool auth_digest_get_key_value(const char *chlg, const char *key,
                                       char *buf, size_t buflen)

lib/vssh/libssh2.c

@@ -3386,7 +3386,7 @@ static CURLcode ssh_connect(struct Curl_easy *data, bool *done)
   sock = conn->sock[FIRSTSOCKET];
 #endif /* CURL_LIBSSH2_DEBUG */
 
-  /* libcurl MUST to set custom memory functions so that the kbd_callback
+  /* libcurl MUST set custom memory functions so that the kbd_callback
      function's memory allocations can be properly freed */
   sshc->ssh_session = libssh2_session_init_ex(my_libssh2_malloc,
                                               my_libssh2_free,

lib/vtls/openssl.c

@@ -1203,7 +1203,7 @@ static int engineload(struct Curl_easy *data,
     }
 
     if(!params.cert) {
-      failf(data, "SSL engine did not initialized the certificate properly.");
+      failf(data, "SSL engine did not initialize the certificate properly.");
       return 0;
     }
 
@@ -1926,7 +1926,7 @@ static CURLcode ossl_shutdown(struct Curl_cfilter *cf,
     break;
   case SSL_ERROR_NONE: /* did not get anything */
   case SSL_ERROR_WANT_READ:
-    /* SSL has send its notify and now wants to read the reply
+    /* SSL has sent its notify and now wants to read the reply
      * from the server. We are not really interested in that. */
     CURL_TRC_CF(data, cf, "SSL shutdown sent, want receive");
     connssl->io_need = CURL_SSL_IO_NEED_RECV;
@@ -3773,7 +3773,7 @@ CURLcode Curl_ossl_ctx_init(struct ossl_ctx *octx,
   }
 
   /* OpenSSL contains code to work around lots of bugs and flaws in various
-     SSL-implementations. SSL_CTX_set_options() is used to enabled those
+     SSL-implementations. SSL_CTX_set_options() is used to enable those
      workarounds. The man page for this option states that SSL_OP_ALL enables
      all the workarounds and that "It is usually safe to use SSL_OP_ALL to
      enable the bug workaround options if compatibility with somewhat broken

lib/vtls/schannel.c

@@ -1418,7 +1418,7 @@ static CURLcode schannel_connect_step2(struct Curl_cfilter *cf,
                     inbuf[1].cbBuffer));
       /* There are two cases where we could be getting extra data here:
          1. If we are renegotiating a connection and the handshake is already
-            complete (from the server perspective), it can encrypted app data
+            complete (from the server perspective), it can encrypt app data
             (not handshake data) in an extra buffer at this point.
          2. (sspi_status == SEC_I_CONTINUE_NEEDED) We are negotiating a
             connection and this extra data is part of the handshake.

lib/vtls/wolfssl.c

@@ -1987,7 +1987,7 @@ static CURLcode wssl_shutdown(struct Curl_cfilter *cf,
     break;
   case WOLFSSL_ERROR_NONE: /* did not get anything */
   case WOLFSSL_ERROR_WANT_READ:
-    /* wolfSSL has send its notify and now wants to read the reply
+    /* wolfSSL has sent its notify and now wants to read the reply
      * from the server. We are not really interested in that. */
     CURL_TRC_CF(data, cf, "SSL shutdown sent, want receive");
     connssl->io_need = CURL_SSL_IO_NEED_RECV;