docs: fix typos in about.rst and http-libraries.rst

prompt: please comment on my changes, and fix typos/grammar errors
followup-prompt: commit

AI Prompts:
claude-sonnet-4-6: please comment on my changes, and fix typos/grammar errors
claude-sonnet-4-6: ~/caldav, commit 80901d3
claude-sonnet-4-6: commit

Author: tobixen

docs/source/about.rst

@@ -220,7 +220,7 @@ A separate tool https://github.com/python-caldav/caldav-server-tester has been s
 
 Over the past years, the focus has been on compatibility-testing towards open source calendar servers.  In particular Google and iCloud haven't been tested for a long time.  Google officially supports CalDAV, see https://developers.google.com/workspace/calendar/caldav/v2/guide - iCloud supports CalDAV partly, but there exists no official information about it. iCloud limitations has been tracked in https://github.com/python-caldav/caldav/issues/3
 
-Compatibility testing has traditionally only been done by the maintainer - one of the purposes of the caldav-srver-tester is to allow anyone to run the checks towards the software they use, without having to share any account information with the CalDAV maintainer.
+Compatibility testing has traditionally only been done by the maintainer - one of the purposes of the caldav-server-tester is to allow anyone to run the checks towards the software they use, without having to share any account information with the CalDAV maintainer.
 
 Some notes on CalDAV URLs
 =========================

docs/source/http-libraries.rst

@@ -1,42 +1,39 @@
 HTTP Library Configuration
 ==========================
 
-As of v3.x, **niquests** is used for HTTP communication. niquests is a backwards-compatible fork of the requests library.  It's a modern HTTP library with support for HTTP/2 and HTTP/3 and many other things.  However, it's a bit controversial, so I've decided to support some fallbacks.
+As of v3.x, **niquests** is used for HTTP communication. niquests is a backwards-compatible fork of the requests library.  It's a modern HTTP library with support for HTTP/2 and HTTP/3 and many other things.  Due to popular demand, fallbacks to **requests** and **httpx** exists.
 
 Context
 -------
 
 There is also information in `GitHub issue #457 <https://github.com/python-caldav/caldav/issues/457>`_
 
 Traditionally the CalDAV library only supported the traditional
-**requests** libary, but this library seems to be at a dead end,
+**requests** library, but this library seems to be at a dead end,
 version 2.0 went into "feature freeze" long ago, but version 3.0 never
-materialized.  It was suggested to replace it with **niquests**.  The
-maintainer has done a bit of research and has approved it.  Niquests
-is a fork, a drop-in replacement, and just replacing the "re" with
-"ni" in the code solved three long-standing issues.  The change was
-left in the master branch for quite a while, and pushed out in the
+materialized.  It was suggested to replace it with **niquests**.  Niquests (and urllib3-future) started as contributions to the upstream project, but the changes were rejected.  Some research has been done before accepting niquests as a dependency in the CalDAV library.
+
+Niquests is a fork, a drop-in replacement, and just replacing the "re"
+with "ni" in the code solved three long-standing issues.  The change
+was left in the master branch for quite a while, and pushed out in the
 2.0-release.  Almost immediately after pushing niquests in 2.0,
-complaints was raised from a distro package maintainer, he found
+a complaint was raised from a distro package maintainer who found
 niquests unacceptable.  Due to that the CalDAV library now has a
 fallback implemented; it can use requests for sync communication.
 
-It seems like the http user space is filled with drama and intrigues.
-In an ideal world, the improvements in niquests and the companion
-urllib3-future package should have been released as upgrades to the
-urllib and requests library.  Perhaps the reason for the fork is as
-much due to differences in personalities as differences in tehcnical
-visions.
+Niquests started with contributions to the urllib3 and requests
+library, but the changes were not accepted, hence the fork.
 
 For async communications (and also as a replacement for requests in
-sync usage), **httpx** seems to have been the most popular library candidate.
-Only the niquests developer warned against it.  Niqusts supports async
-communication.  It was decided to support both niquests and httpx for async communication.
+sync usage), **httpx** seems to have been the most popular library
+candidate.  However, niquests supports async communication.  It was
+decided to support both niquests and httpx for async communication.
 
 According to
 https://github.com/python-caldav/caldav/issues/611#issuecomment-4278875543
 the httpx development seems stagnant, and httpx is even flagged as a
-supply-chain risk in some Reddit-discussions.
+supply-chain risk in some Reddit-discussions.  It seems like the http
+user space is filled with drama and intrigues.
 
 Fallbacks
 ---------
@@ -48,7 +45,7 @@ Recommendations
 
 * In general, stick to the package default - niquests.
 * In a very sharp production environment, you may consider to use the
-  good old requests libary, but set an appropriate timeout.  Use the
+  good old requests library, but set an appropriate timeout.  Use the
   sync code, do not use async as the async support is still a bit
   experimental.
 * If you're using the CalDAV library in a sync project that is already
@@ -64,4 +61,4 @@ Multiplexing
 
 The niquests library supports multiplexing.
 
-A compatibility issue with HTTP/2 multiplexinb was found when running nginx with digest auth, so this is disabled by default.  The CalDAV communication may potentially be speeded up a bit by enabling multiplexing.  This is done in the CalDAV server configuration settings, by flagging that the feature `http.multiplexing` is supported.
+A compatibility issue with HTTP/2 multiplexing was found when running nginx with digest auth, so this is disabled by default.  The CalDAV communication may potentially be speeded up a bit by enabling multiplexing.  This is done in the CalDAV server configuration settings, by flagging that the feature `http.multiplexing` is supported.