Fix misspellings (#2908)

lu4p committed Dec 5, 2019 at 00:28 UTC 68adfdc559e3a97f19ec85ec2e1e5d3ceae20161

3 files changed +3 -3

README.md

+1 -1

@@ -185,7 +185,7 @@ The following is a non-comprehensive list of significant improvements over Caddy

185 - 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**.

186 - 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.)

187 - Using [XDG standards](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables) instead of dumping all assets in `$HOME/.caddy`.

188 -- 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.

188 +- 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.

189 - 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.

190 - Can specify different storage mechanisms in different parts of the configuration, if more than one is needed.

191 - "Top-level" Caddy modules are simply called "apps" because literally any long-lived application can be served by Caddy 2.

modules/caddyhttp/reverseproxy/reverseproxy.go

+1 -1

@@ -234,7 +234,7 @@ func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request, next caddyht

234 // etc.) - this obviously has a perf

235 // overhead and makes the proxy at

236 // risk of exhausting memory and more

237 - // suseptible to slowloris attacks,

237 + // susceptible to slowloris attacks,

238 // so it is strongly recommended to

239 // only use this feature if absolutely

240 // required, if read timeouts are set,

modules/caddyhttp/server.go

+1 -1

@@ -399,7 +399,7 @@ func errLogValues(err error) (status int, msg string, fields []zapcore.Field) {

399 // (into the urlCopy parameter, which should be on the

400 // stack), req.RequestURI, and req.RemoteAddr. Notably,

401 // headers are not copied. This function is designed to

402 -// be very fast and efficient, and useful primarly for

402 +// be very fast and efficient, and useful primarily for

403 // read-only/logging purposes.

404 func originalRequest(req *http.Request, urlCopy *url.URL) http.Request {

405 cloneURL(req.URL, urlCopy)