Fix misspellings (#2908)

3 files changed, 3 insertions, 3 deletions

diff --git a/README.md b/README.md
index 029eebc..f1bcda6 100644
--- a/README.md
+++ b/README.md
@@ -185,7 +185,7 @@ The following is a non-comprehensive list of significant improvements over Caddy
 - Silky-smooth graceful reloads. Update the configuration up to dozens of times per second with no dropped requests and very little memory cost. Our unique graceful reload technology is lighter and faster **and works on all platforms, including Windows**.
 - An embedded scripting language! Caddy2 has native Starlark integration. Do things you never thought possible with higher performance than Lua, JavaScript, and other VMs. Starlark is expressive, familiar (dialect of Python), _almost_ Turing-complete, and highly efficient. (We're still improving performance here.)
 - Using [XDG standards](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables) instead of dumping all assets in `$HOME/.caddy`.
-- Caddy plugins are now called "Caddy modules" (although the terms "plugin" and "module" may be used interchangably). Caddy modules are a concept unrelated [Go modules](https://github.com/golang/go/wiki/Modules), except that Caddy modules may be implemented by Go modules. Caddy modules are centrally-registered, properly namespaced, and generically loaded & configured, as opposed to how scattered and unorganized Caddy 1-era plugins are.
+- Caddy plugins are now called "Caddy modules" (although the terms "plugin" and "module" may be used interchangeably). Caddy modules are a concept unrelated [Go modules](https://github.com/golang/go/wiki/Modules), except that Caddy modules may be implemented by Go modules. Caddy modules are centrally-registered, properly namespaced, and generically loaded & configured, as opposed to how scattered and unorganized Caddy 1-era plugins are.
 - Modules are easier to write, since they do not have to both deserialize their own configuration from a configuration DSL and provision themselves like plugins did. Modules are initialized pre-configured and have the ability to validate the configuration and perform provisioning steps if necessary.
 - Can specify different storage mechanisms in different parts of the configuration, if more than one is needed.
 - "Top-level" Caddy modules are simply called "apps" because literally any long-lived application can be served by Caddy 2.
diff --git a/modules/caddyhttp/reverseproxy/reverseproxy.go b/modules/caddyhttp/reverseproxy/reverseproxy.go
index 98118c2..87895e2 100644
--- a/modules/caddyhttp/reverseproxy/reverseproxy.go
+++ b/modules/caddyhttp/reverseproxy/reverseproxy.go
@@ -234,7 +234,7 @@ func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request, next caddyht
 	// etc.) - this obviously has a perf
 	// overhead and makes the proxy at
 	// risk of exhausting memory and more
-	// suseptible to slowloris attacks,
+	// susceptible to slowloris attacks,
 	// so it is strongly recommended to
 	// only use this feature if absolutely
 	// required, if read timeouts are set,
diff --git a/modules/caddyhttp/server.go b/modules/caddyhttp/server.go
index 17860ed..fef887d 100644
--- a/modules/caddyhttp/server.go
+++ b/modules/caddyhttp/server.go
@@ -399,7 +399,7 @@ func errLogValues(err error) (status int, msg string, fields []zapcore.Field) {
 // (into the urlCopy parameter, which should be on the
 // stack), req.RequestURI, and req.RemoteAddr. Notably,
 // headers are not copied. This function is designed to
-// be very fast and efficient, and useful primarly for
+// be very fast and efficient, and useful primarily for
 // read-only/logging purposes.
 func originalRequest(req *http.Request, urlCopy *url.URL) http.Request {
 	cloneURL(req.URL, urlCopy)