Caddy · XB Field Notes

Caddy automates HTTPS issuance and renewal

Thu, 21 Jan 2027 00:00:00 +0000

Caddy can obtain and renew managed certificates without an operator manually implementing ACME. That removes repetitive work, not the prerequisites for issuance or the need to notice failures. A valid certificate today proves neither that the next renewal can complete nor that every TLS hop uses the same certificate. Identify the names, validation route, storage, and termination boundary first.

Give automatic HTTPS a name

Automatic HTTPS activates when Caddy knows a qualifying hostname or address through its configuration, subject to documented exceptions and overrides. A hostname in a Caddyfile site address is one common trigger. The file_server directive serves files; it is not, by itself, a request for a public certificate for an unspecified domain.

The command-line distinction is concrete: bare caddy file-server defaults to port 80. Supplying --domain makes it attempt HTTPS for that hostname and changes the default listener to port 443. Neither command spelling proves that DNS, port forwarding, or certificate authorization is correct. Explicit HTTP configuration and manually loaded certificates also change automatic behavior.

Local development has a different trust boundary. Caddy can use its local certificate authority for internal names. Clients must trust that authority through an appropriate installation process; a certificate working on one machine does not make it publicly trusted. Do not distribute a private CA’s signing key to solve a client trust problem.

Match the challenge to the route

Caddy enables HTTP-01 and TLS-ALPN-01 by default. HTTP-01 validation enters through public port 80, while TLS-ALPN-01 uses port 443 and a special TLS handshake. Caddy can choose between available challenges. A failed HTTP challenge does not imply that DNS validation is the only possible alternative; inspect which methods and routes are actually available.

A proxy or CDN can interfere with either path, but its presence does not automatically make issuance impossible. HTTP challenge traffic may be forwarded correctly even when the CDN terminates ordinary HTTPS. DNS-01 proves control through a TXT record and does not require the requesting server to accept inbound validation traffic. It needs a supported provider integration and appropriately scoped DNS credentials.

When it breaks

Stale A or AAAA records, blocked ports, incorrect forwarding, or a changed CDN rule can break validation after the first issuance succeeded. Check both address families and the actual failed challenge in logs. Repeatedly deleting storage and retrying is a poor diagnostic: it removes reusable certificate state and can increase unnecessary issuance attempts.

Persist Caddy’s data storage across replacement instances and protect it because it contains sensitive key material. Multiple instances need a storage arrangement with the coordination semantics Caddy expects. A directory merely bearing the same name on several machines is not shared storage. Test recovery of that configuration without exposing keys in logs or source control.

Automation can fail while the existing certificate still works. Monitor renewal errors and the expiry of the certificate clients actually receive, leaving enough time for response. A successful origin renewal does not prove the CDN’s public certificate changed. Likewise, CDN TLS does not remove the need to secure and validate a separate HTTPS origin connection.

Use a staging issuer for issuance experiments, and keep its untrusted test certificates out of production. DNS credential rotation needs a controlled validation check. Choose alert lead time around response requirements and certificate lifetime; a fixed thirty-day arithmetic example is not a specification of Caddy’s renewal schedule.

Caddy certificate lifecycle: mechanism and evidence boundaries.

Check it quickly

Save this as expiry_alert.py and run python3 expiry_alert.py. Use assertions enabled, without -O or PYTHONOPTIMIZE. It needs only the standard library and uses a fixed UTC observation time. The synthetic thirty-day threshold belongs to this operator alert, not to Caddy. No domain, certificate authority, network listener, key, or system trust setting is touched.

from datetime import datetime, timedelta, timezone

# An operator-chosen alert threshold, not Caddy's renewal scheduler.
ALERT_BEFORE = timedelta(days=30)
NOW = datetime(2026, 10, 15, 12, tzinfo=timezone.utc)


def expiry_alert(not_after, now):
 for value in (not_after, now):
 if value.tzinfo is None or value.utcoffset() is None:
 raise ValueError("timezone-aware timestamps required")
 remaining = not_after - now
 if remaining <= timedelta(0):
 return "expired"
 if remaining <= ALERT_BEFORE:
 return "warning"
 return "ok"


for name, days, expected in [
 ("fresh", 80, "ok"), ("due", 20, "warning"),
 ("boundary", 30, "warning"), ("expired", -1, "expired"),
]:
 not_after = NOW + timedelta(days=days)
 actual = expiry_alert(not_after, NOW)
 assert actual == expected
 print(f"{name}: remaining={days}d alert={actual}")
assert expiry_alert(NOW, NOW) == "expired"
try:
 expiry_alert(NOW.replace(tzinfo=None), NOW)
except ValueError:
 print("naive timestamp rejected")
else:
 raise AssertionError("missing timezone accepted")
print("PASS: expiry alert boundaries; no certificate issuance tested")

The four printed cases are ok, warning, warning, and expired. Exactly thirty days is included in the warning interval; expiry itself is classified separately. The negative case supplies a naive expiry timestamp; the function also checks the observation time, but that separate branch is not exercised. These assertions verify the alert’s declared boundaries rather than relying on today’s date or a particular certificate lifetime.

Retained exact records cover the unchanged arithmetic fixture; this source review did not rerun it. The exercise does not run Caddy, issue a certificate, or observe renewal. For deployment evidence, verify the served certificate and configured challenge route, then observe successful renewal using the intended persistent storage. Keep that operational evidence separate from this small, repeatable date-arithmetic check.

Sources

Python assert statement, optimization omits assertions and any calls inside them, checked 2026-10-18.
Caddy automatic HTTPS, activation, local trust, challenge selection, and storage, checked 2026-10-15.
Caddy file-server command, default listener and the domain flag, checked 2026-10-15.
Let’s Encrypt challenge types, validation ports, DNS automation, and scoped credentials, checked 2026-10-15.
Let’s Encrypt rate limits, staging for experiments and issuance failures, checked 2026-10-15.

Ship a static site and prove the edge agrees

Tue, 11 Aug 2026 00:00:00 +0000

A release is complete when the required public-edge checks agree with the artifact you chose, not merely when upload exits zero. This tutorial connects build, check, publish, and verify, while distinguishing local checks from deployment changes. Publishing changes the server; only the final probes are read-only network observations.

The commands assume Bash, GNU find/sort/sha256sum, rsync, Python 3, and the project’s pinned Hugo. Run build steps from the repository root. Before touching a live host, rehearse the directory-switch example in a disposable directory. Know the actual serve root, who owns deployment, the previous release target, and the rollback procedure. The /srv layout below is an example requiring an already configured deployment, not something this repository automatically installs.

The pointer switch changes the failure boundary. Before it, stop with the old release; after it, roll back explicitly and verify again. Disk checks and edge samples establish different facts.

1. Build one artifact from recorded inputs

Start from a clean source revision. Run the project build and record the installed generator version:

set -eu
git status --short
git rev-parse HEAD
hugo version
make build

An empty short status supports a clean-tree claim; the command itself does not enforce one. Inspect any changes before calling the build a release of that commit. make build writes data/buildinfo.toml with the short commit and current UTC build time, then generates public/. The rendered marker identifies the recorded inputs; it is not proof that a dirty checkout contained only that commit.

Pinning Hugo and the vendored theme reduces drift, but the build-time field means ordinary builds at different times need not be byte-identical. Build the chosen release once, validate it, and transfer that exact artifact rather than rebuild independently on the server.

2. Check the complete offline contract

make check checks generated visuals, offline-pack freshness, internal links, script-free output, source links, and downloadable checksums for the current artifact. For the full repository gate, use:

set -eu
make verify
make check-upstream

The full gate also runs regression tests, bilingual-post checks, and review-ledger freshness, then rebuilds and checks output. Therefore create the release manifest only after the last build. Build success and a current review ledger do not establish technical correctness of every article or prove the public server uses the intended headers. Page counts and timings vary; retain actual output rather than comparing to a copied example count.

3. Name the artifact bytes in a manifest

Before hashing, verify that public/ contains only directories and regular files, and stop all writers until staging is complete. The commands below do not create a snapshot or check for every special-file type. Keep the manifest outside public/ so it cannot hash itself. NUL-delimited filenames preserve spaces and other shell-sensitive characters:

set -euo pipefail
manifest="$(pwd)/release.sha256"
(
 cd public
 find . -type f -print0 | LC_ALL=C sort -z | xargs -0 sha256sum
) > "$manifest"
(cd public && sha256sum -c "$manifest")
sha256sum "$manifest"

GNU checksum lines contain the digest before the filename. A successful sha256sum -c verifies listed files, not that no extra files exist. A new empty release directory avoids stale destination files, but does not detect extra source files added after hashing. To establish complete regular-file inventory parity, recompute the staged manifest with the same path/sort/hash rules and compare the full lists before selection. Inspect symlinks separately: find -type f does not include them, and serving an unintended symlink can expose files outside the intended root. Keep the manifest and its own digest with the release record; a checksum proves consistency against that manifest, not authenticity of an untrusted manifest.

4. Stage and select a complete release

Assume Caddy already serves /srv/www/example-site/current, which is a symlink into releases/, with correct ownership and read permissions. The releases parent must already exist. Serialize deployers and choose a unique release ID. Run this block as a standalone Bash script on the deployment machine, from the directory containing the validated public/ and release.sha256. Check the artifact’s ownership and readable permissions against the deployment policy before running it. It establishes its own manifest path and fail-fast policy; a failed precondition, copy, or checksum must stop before pointer selection. It refuses symlinks inside the staged artifact and is a mutating deployment step.

set -euo pipefail
base=/srv/www/example-site
manifest="$(pwd)/release.sha256"
test -f "$manifest"
test -d public
release_id=20261015T120000Z
release="$base/releases/$release_id"
test -L "$base/current"
previous=$(readlink "$base/current")
mkdir "$release" # Fail if this release already exists.
rsync -a public/ "$release/"
(cd "$release" && sha256sum -c "$manifest")
links=$(find "$release" -type l -print -quit)
if [ -n "$links" ]; then
 echo "Refusing symlinks in the staged artifact" >&2
 exit 1
fi
# Ownership and readable permissions must match the deployment policy.
python3 - "$base" "$release_id" <<'PYTHON'
from pathlib import Path
import os, sys, uuid
base = Path(sys.argv[1])
release = base / "releases" / sys.argv[2]
current = base / "current"
if not current.is_symlink() or not release.is_dir():
 raise SystemExit("Expected current symlink and a complete release directory")
pending = base / (".current-" + uuid.uuid4().hex)
pending.symlink_to(os.path.relpath(release, base), target_is_directory=True)
os.replace(pending, current)
print("selected:", os.readlink(current))
PYTHON
printf 'Previous target: %s\n' "$previous"

The symlink replacement uses one same-filesystem rename because the pending link and current share a parent. An ordinary mv new existing-directory does not exchange non-empty directories. Do not convert an existing real-directory serve root with this snippet; plan that migration separately. Validate the actual server’s root resolution and filesystem behavior in staging.

The old target stays on disk, but that alone does not make an old asset URL reachable after switching. Retain fingerprinted asset bytes in the newly served namespace or a stable asset store. Multiple browser requests can span releases, and caches may keep old HTML. Atomic namespace replacement is not cross-request snapshot isolation or a power-loss durability guarantee.

5. Verify delivered bytes and policy

After switching, compare a sampled public body with the corresponding artifact file, using a fixed representation selection:

set -euo pipefail
url=https://www.xbcatm.com/
status=$(curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -D served.headers -o served.html -w '%{http_code}' "$url")
test "$status" = 200
cmp public/index.html served.html
sh public/downloads/check-http-headers.sh "$url"

Run this block from the same artifact directory used for staging. The header helper is the trusted copy inside that artifact; a source checkout is not required for this step. cmp succeeding establishes exact parity for this homepage sample. An unexpected redirect, proxy-generated 200 error page, CDN transformation, or encoded response needs investigation. Inspect served.headers, including Content-Encoding, cache age, CSP, and content type. The header helper prints responses and final status; it does not enforce all your expectations.

Repeat for Chinese content, a nested article, CSS, an SVG, a download, redirects, and the error route. Document the URL-to-file mapping, including directory indexes. The shown listed-file check establishes consistency for those files, not a complete staged inventory or what all public cache nodes deliver. A complete edge claim requires broader retrieval and representation-aware checks; a few probes remain samples.

If a post-switch check fails, the new release is still selected until you act. Use a new temporary symlink targeting the recorded previous value, atomically replace current again, and repeat the probes. Do not merely move the new tree away, and do not delete evidence or the previous release while diagnosing.

6. Check TLS identity and the expiry window separately

From the repository root, the expiry helper is:

sh static/downloads/check-tls-expiry.sh www.xbcatm.com 30

It extracts a certificate, prints dates, and checks the remaining expiry interval. It is not a full TLS identity test: its current implementation does not make hostname/trust verification failure fatal. Follow the public-edge trust tutorial for an explicit verified handshake and SAN check. Do not infer trust-chain or revocation success from “valid for at least 30 days.”

A near-expiry certificate is a separate release concern. Preserve the actual notAfter, trust result, and client environment rather than copying a historical issuer or date into the release log.

7. Include the DNS cache window when DNS changes

A content-only release need not change DNS. If the host or edge changes, preserve service at the old destination while caches expire. Lowering TTL at the moment of the change does not shorten entries already cached with the old TTL. Resolver serve-stale behavior, negative caching, and client caches can complicate the window; TTL is not a universal deadline by which every client has moved. CAA changes affect issuance policy, not routing to the new content.

8. Keep a rehearsed restore path

The previous directory is useful for fast rollback, but it is not an independent backup. A disk failure, accidental cleanup, or compromised deployment account may affect every local release. Retain source, build inputs, configuration, and an appropriate separate artifact backup; rehearse restoring them in isolation. One successful rehearsal is evidence about that recovery path at that time, not a permanent guarantee for later changes.

9. Record the outcome precisely

Keep the source revision and clean-tree status, build metadata and tool versions, manifest digest, selected and previous targets, probe timestamps, HTTP/TLS observations, and any rollback. State whether verification covered samples, all mapped URLs, or multiple vantage points. If a gate failed, record the failure and recovery rather than “it worked.”

Before selection, a failure can leave the old release untouched. After selection, recovery is an explicit operation with its own verification. This distinction makes the release path auditable without pretending every failure automatically restores the old tree.

Sources

rsync manual, archive copying and source trailing-slash semantics, checked 2026-10-15.
RFC 8767: Serving Stale Data, DNS serve-stale behavior beyond TTL expiry, checked 2026-10-15.
GNU sha256sum manual, Debian package, checksum output and verification flags, checked 2026-10-15.
Python os.replace, atomic replacement and filesystem limits, checked 2026-10-15.
Caddy file_server, root and symlink handling, checked 2026-10-15.
curl manual, status capture, headers, and content decoding, checked 2026-10-15.
OpenSSL s_client, explicit certificate verification, checked 2026-10-15.
Reproducible Builds: definitions, artifact identity versus reproducibility, checked 2026-10-15.

Security headers should describe the actual page

Thu, 23 Jul 2026 00:00:00 +0000

Security headers are not a substitute for secure code, but they make the browser enforce useful boundaries. The policy should describe the page that is actually served, not a generic template copied from another project.

Treat headers as a deployment contract: match actual resources, distinguish enforced and report-only policy, and verify exact host scope and browser behavior.

Start from the resource graph

If a site serves HTML, a local stylesheet, a favicon, and no executable JavaScript, a narrow policy can be understandable:

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

The script-src 'none' choice is only correct while the site does not require executable scripts. Adding search, comments, or an analytics tag changes the resource graph and should trigger a deliberate policy review.

Add transport and framing protections

For an HTTPS-only site, the following headers are common starting points:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

Only enable HSTS with includeSubDomains when every subdomain is prepared to serve HTTPS. A header is a contract with future deployments, not merely a score in a scanner.

Check behavior, not just presence

Request a normal page, a missing page, and a static asset. Error responses should carry the same important security headers as successful responses. Also confirm that compression and caching do not change the content type or expose an internal path.

The Caddy example in this site is a starting point, not a universal policy. Adapt the host names, certificate handling, and application routes to your own deployment.

Deliver the CSP as a response header. frame-ancestors is ignored in a meta policy and does not inherit default-src; form-action also needs its own directive. style-src 'self' does not allow inline styles by itself, so test the generated theme, including dark mode. Keep data: in img-src only when the page actually needs data images.

Content-Security-Policy-Report-Only can reveal violations during a rollout, but does not enforce the policy; a reporting endpoint needs separate configuration. Verify enforcement in a real browser as well as checking headers. HSTS is learned from valid HTTPS responses; with includeSubDomains it also applies to descendants of the host that sets it: a policy on www.example.test does not cover the parent example.test or sibling api.example.test. Gradually increase the lifetime after checking that exact scope.

Sources

MDN: Content Security Policy guide, CSP directive names and syntax, checked 2026-07-23.
MDN: Strict-Transport-Security, HSTS directives and deployment cautions, checked 2026-07-23.
Caddy header directive, response header manipulation directives, checked 2026-07-23.
W3C Content Security Policy Level 3, response-header delivery, directive fallbacks, framing, and report-only policies; current working draft, checked 2026-10-15.
RFC 6797 — HTTP Strict Transport Security, valid HTTPS delivery and host/descendant matching in sections 8.1–8.3, checked 2026-10-15.

Compression changes the selected HTTP representation

Mon, 29 Jun 2026 00:00:00 +0000

Compression saves transfer bytes, but it also creates another representation of a resource. A client announces acceptable content codings with Accept-Encoding; the server describes the applied coding with Content-Encoding.

Compression selects representation bytes, so negotiation, cache matching, and validators must agree. Distinct coded bytes need distinct strong tags. Compare the decoded download with the artifact; an encoded Content-Length need not equal the decoded file size.

Make negotiation visible

When a response can change according to Accept-Encoding, include that request field in Vary. This tells shared caches that a compressed response and an identity response are not interchangeable cache entries.

Compare the two paths instead of checking only a browser request:

curl -sS -D - -o /dev/null \
 -H 'Accept-Encoding: identity' https://www.example.test/
curl -sS --compressed -D - -o /dev/null \
 https://www.example.test/

Inspect Content-Encoding, Vary, Content-Length when present, and the validator. Strong entity tags must differ when content coding changes the representation bytes. A shared weak tag is possible for semantically equivalent variants, but it cannot support strong comparison. Check conditionals against the same negotiated representation.

Compress appropriate content

Text formats such as HTML, CSS, JSON, XML, and SVG usually benefit from compression. Formats that are already compressed might not. Caddy’s encode directive negotiates supported encodings and normally avoids encoding a response without an appropriate content type or minimum size.

Do not add compression solely to satisfy a score. Measure a representative response, confirm that the edge emits the intended headers, and verify that downloadable files retain the correct content type and checksum after transfer decoding.

With --compressed, curl decodes the body automatically but leaves saved response headers unchanged. A reported Content-Length, when present, describes encoded content, so it need not equal the size of the decoded download. Compare a checksum with the artifact only after content decoding; HTTP transfer framing is a separate layer. The option also does not guarantee compression: inspect the actual response, especially for small or already-compressed files.

Sources

RFC 9110 — HTTP Semantics, content codings and Vary, checked 2026-10-15.
Caddy encode directive, content encoding selection and negotiation, checked 2026-10-15.
curl manual, --compressed, checked 2026-10-15.

Certificate expiry is a date, not a dashboard color

Wed, 10 Jun 2026 00:00:00 +0000

An HTTPS process can be healthy while the public certificate is close to expiry, issued for the wrong name, or served differently on another edge. A useful check asks the public endpoint for the certificate it would give to a real client.

Inspect the certificate a real client sees, then verify separately. Expiry alerts need a service-specific response threshold, handshake checks, renewal-failure alerts, and sampling of relevant edges and address families.

Include the hostname

TLS virtual hosting depends on the server name. Pass the hostname as SNI and inspect the peer certificate:

host=www.example.test
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
 | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

The command is read-only. It does not renew anything and it does not prove that every intermediate certificate is accepted by every client. It does give you the not-before, not-after, subject, issuer, and fingerprint of the certificate presented for that hostname.

Alert on a threshold

Choose a threshold that leaves time for a failed renewal, a DNS problem, and a human response. The exact number belongs to the service’s recovery target; a universal “30 days” rule is not a substitute for that decision. The companion TLS expiry check prints the expiry and exits non-zero when the remaining interval is below the threshold you pass.

Run the check from outside the host when possible. A local process may see a different listener, certificate file, or proxy path than a visitor on the public network.

Separate observation from verification

SNI selects a virtual host; it does not verify that the certificate matches that name. This pipeline prints a certificate even when s_client reports verification problems, and stderr is suppressed. Use a separate hostname-and-chain verification check with visible diagnostics and a known trust store. Do not turn this inspection pipeline’s final exit code into a TLS-health verdict.

The companion helper tests notAfter with OpenSSL -checkend; it does not establish hostname validity, trust, revocation status, or that notBefore has arrived. Pair expiry alerts with handshake checks and renewal-failure alerts. Choose a threshold smaller than the certificate’s normal lifetime, especially for short-lived certificates, and sample each relevant edge/address family.

Sources

Caddy Automatic HTTPS, automatic TLS certificate management, checked 2026-10-15.
OpenSSL s_client documentation, SNI and certificate inspection options, checked 2026-10-15.
OpenSSL x509 documentation, certificate parsing, dates, and fingerprints, checked 2026-10-15.

A static server should have one obvious root

Thu, 04 Jun 2026 00:00:00 +0000

The most useful property of a static deployment is that an operator can answer “which directory served this response?” without reading application code. Caddy’s root and file_server directives provide that boundary directly.

Make the serving directory explicit. Audit symlinks and read/traverse permissions, then verify the actual response at the edge.

Make the root explicit

A minimal site block can be kept close to the artifact layout:

www.example.test {
 root * /srv/example-site
 encode zstd gzip

 header {
 -Server
 X-Content-Type-Options nosniff
 X-Frame-Options DENY
 Referrer-Policy strict-origin-when-cross-origin
 }

 file_server
}

The hostname and path are placeholders; www.example.test is not a publicly issuable production name. Use an owned, resolvable hostname for production and plan local TLS trust separately for a test environment. The release command should publish a complete directory, verify it, and only then make that directory the configured root. Keep the prior known-good directory until the new one has passed smoke tests.

Check the edge, not only the file tree

Request an HTML page, a downloadable text file, and a missing path. Compare content types and status codes with the local artifact. A 404 page that returns 200 is a deployment bug even if the page looks polished.

When Caddy manages HTTPS, certificate provisioning and HTTP-to-HTTPS redirects are part of the edge behavior. Test the redirect from the bare HTTP listener and the certificate name from the public hostname. Do not infer success from a healthy process alone.

A root is a publication boundary, not a sandbox

Keep source control metadata, backups, credentials, and private configuration outside the published tree. Caddy follows symlinks inside the root, so a link can expose files outside it. Check both the artifact contents and the serving user’s read/traverse permissions. Also, merely placing 404.html in the tree does not configure a custom error handler; verify the missing-route status and error-page behavior you intend.

Sources

Caddy file_server directive, file serving, root, and index defaults, checked 2026-10-15.
Caddy Automatic HTTPS, automatic TLS and issuance behavior, checked 2026-10-15.
Static-site release checklist, local companion resource.
Caddy header directive, response header operations, checked 2026-10-15.
RFC 7034 — X-Frame-Options, the DENY framing policy, checked 2026-10-15.
MDN: X-Frame-Options, framing options, checked 2026-10-15.
RFC 6761 — Special-Use Domain Names, reserved .test names, checked 2026-10-15.

Caddy · XB Field Notes

Caddy automates HTTPS issuance and renewal

Give automatic HTTPS a name

Match the challenge to the route

When it breaks

Check it quickly

Further reading

Sources

Ship a static site and prove the edge agrees

1. Build one artifact from recorded inputs

2. Check the complete offline contract

3. Name the artifact bytes in a manifest

4. Stage and select a complete release

5. Verify delivered bytes and policy

6. Check TLS identity and the expiry window separately

7. Include the DNS cache window when DNS changes

8. Keep a rehearsed restore path

9. Record the outcome precisely

Sources

Security headers should describe the actual page

Start from the resource graph

Add transport and framing protections

Check behavior, not just presence

Sources

Compression changes the selected HTTP representation

Make negotiation visible

Compress appropriate content

Sources

Certificate expiry is a date, not a dashboard color

Include the hostname

Alert on a threshold

Separate observation from verification

Sources

A static server should have one obvious root

Make the root explicit

Check the edge, not only the file tree

A root is a publication boundary, not a sandbox

Sources