Tutorial · XB Field Notes

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.

Read a live edge the way a client does

Fri, 07 Aug 2026 00:00:00 +0000

The HTTP-foundations notes each take one contract and show single pieces of evidence. This tutorial walks the whole path a single client request touches, in order, using only read-only commands. The aim is to distinguish protocol requirements from choices made by a particular server, rather than demand the same status and headers from every endpoint.

We use www.xbcatm.com throughout. Replace it with the host you are inspecting. The requests use safe HTTP methods; they can still create access logs or consume rate limits. Inspect only endpoints you are permitted to query. Output blocks below are illustrative, not current production measurements. Run shell snippets in a disposable working directory, keep failures visible, and record time and client version.

Keep the selected representation consistent, and interpret each observed response within its own contract. No live edge was queried for this illustration.

1. Start with what a method may ask

Before you read a response body, pin down what the server will allow you to ask. A static handler often supports GET and HEAD, while a proxy may also implement OPTIONS. Ask the edge about the target resource:

$ curl -sS --max-time 20 -D - -o /dev/null -w 'OPTIONS -> HTTP %{http_code}\n' -X OPTIONS https://www.xbcatm.com/
HTTP/2 405
allow: GET, HEAD

OPTIONS -> HTTP 405

405 Method Not Allowed is valid when OPTIONS is recognized but not supported for this resource, and a 405 must include Allow. A successful 200 or 204 OPTIONS response can also be correct. 501 means the method is not implemented by the server. An OPTIONS result is not proof that every other method behaves correctly. Do not send POST merely to test rejection on an unfamiliar live service: it is not a safe method, and a 200 alone does not describe its side effects.

2. Read the representation line

The first line tells you the negotiated exchange; the headers then tell you what kind of bytes are coming. Capture them exactly as a client sees them, discarding the body:

$ curl -sS --max-time 20 -D - -o /dev/null https://www.xbcatm.com/
HTTP/2 200
accept-ranges: bytes
content-length: 15890
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:
content-type: text/html; charset=utf-8
etag: "dkx84jwth7nkc9e"
last-modified: Mon, 24 Aug 2026 13:55:23 GMT
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

Three headers deserve a pause. content-type: text/html; charset=utf-8 names the media type, and content-type-and-nosniff shows why it must describe the actual bytes you send. etag: "dkx84jwth7nkc9e" hands you a strong validator. x-content-type-options: nosniff constrains browser MIME handling, notably for script and stylesheet fetches; it does not validate the body as HTML. Each is evidence, not decoration, and together they say: this response advertises metadata to compare with its body and intended policy. A syntactically strong ETag is a server assertion, not independent proof of a content hash.

3. Compare HEAD and GET for the same representation

HEAD has GET semantics without a response body. Servers should return the same header fields but may omit fields whose values are determined only while generating content. Content-Length is optional; if sent on HEAD, it must equal the size of the content a corresponding GET would send. Compare stable requests with the same encoding and other selection headers:

$ curl -sSI --max-time 20 -H 'Accept-Encoding: identity' https://www.xbcatm.com/ | grep -i content-length
content-length: 15890
$ curl -sS --max-time 20 -H 'Accept-Encoding: identity' https://www.xbcatm.com/ | wc -c
15890

They match: 15890 on both. That is the head-request-parity contract. An absent HEAD length alone is not a protocol violation. A mismatched value needs investigation, including a deployment between the requests or different selected representations. A pipeline to wc can hide curl failure in shells without pipefail; for an automated gate, save the body only after curl succeeds and count that file.

4. Ask for precise bytes with a range

Because the origin knows its representation, it can serve part of it. A range request asks for a byte span and gets only that span:

$ curl -sS --max-time 20 -D - -o /dev/null -H 'Accept-Encoding: identity' -H 'Range: bytes=0-99' -w 'HTTP %{http_code} bytes=%{size_download}\n' https://www.xbcatm.com/
HTTP/2 206
content-range: bytes 0-99/15890
content-length: 100

HTTP 206 bytes=100

For a representation at least 100 bytes long, a successful single-range response should have 206, a matching Content-Range: bytes 0-99/…, and 100 content bytes. A server may legally ignore Range and return a full 200; that does not imply it lacks validators. An unsatisfiable range can return 416. A plain Range request does not require an ETag. Resuming a particular representation with If-Range, or safely combining partial responses, needs the relevant strong-validator rules. Ranges refer to the selected encoded bytes, hence the explicit identity encoding here.

5. Let the cache revalidate with a validator

Now combine method, representation, and byte selection through caching. A fresh stored response may be reusable without checking a validator. To test revalidation, capture the current response and replay its actual ETag using the same representation selection. Do not copy an old tag from an article:

set -eu
url=https://www.xbcatm.com/
work=$(mktemp -d)
status=$(curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -D "$work/headers" -o "$work/body" -w '%{http_code}' "$url")
test "$status" = 200
etag=$(awk 'tolower($1)=="etag:" {sub(/\r$/, ""); sub(/^[^:]*:[ \t]*/, ""); print; exit}' "$work/headers")
test -n "$etag" || { echo 'No ETag: inspect Last-Modified instead' >&2; exit 1; }
curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -H "If-None-Match: $etag" -D - -o /dev/null \
 -w 'HTTP %{http_code}\n' "$url"

Run this fragment as a standalone shell script. It must finish the initial transfer and require status 200 before storing a usable response; an error representation can also have an ETag. If the selected representation still matches and normal processing succeeds, expect 304 and reuse that complete stored body with updated metadata. A changed representation can correctly return 200. Keep the temporary directory while inspecting the result, then remove only that generated directory when finished. If-None-Match uses weak comparison, so a 304 need not prove byte identity. Freshness lifetime and current age decide reuse without validation; a validator answers a different question and does not itself set that lifetime.

6. Negotiate a smaller representation when you can

The same content can travel in fewer bytes when the client says it can decompress. Offer gzip and watch the body shrink while the meaning stays identical:

$ curl -sS --max-time 20 -H 'Accept-Encoding: identity' -o /dev/null -w 'no-enc: %{size_download} bytes\n' https://www.xbcatm.com/
$ curl -sS --max-time 20 -o /dev/null -H 'Accept-Encoding: gzip' -w 'gzip: %{size_download} bytes\n' https://www.xbcatm.com/
no-enc: 15890 bytes
gzip: 4368 bytes

These example sizes illustrate a possible reduction; the server may choose identity instead. That is the http-compression-negotiation note’s core idea: changing the selected representation changes the bytes on the wire, and the metadata (content-length, encoding) changes with it. A client that requests compression and a cache that stores the encoded form must agree on which representation they selected, otherwise the cache can serve a mismatch. Inspect Content-Encoding and Vary: Accept-Encoding, not just the byte count. A manually supplied Accept-Encoding does not make curl automatically decompress; --compressed requests supported encodings and decodes the response. Compare decoded bodies to establish equal content, and do not assume strong ETags remain identical across encodings.

7. Follow the story when a URL changes

When identity changes, the response should say where the story continues rather than guess the body:

$ curl -sS --max-time 20 -o /dev/null -w '%{http_code} -> %{redirect_url}\n' -I http://www.xbcatm.com/ | head -1
308 -> https://www.xbcatm.com/

308 Permanent Redirect keeps the method and preserves the story, which is the concern of redirects-and-status-codes. Whether it is a 301/308 for a permanent move, or a 404 handled by the site, the status line is the first sentence of the story and should be read before the body.

8. Let the crawler read the map last

The edge is also read by machines that do not request HTML at all. Discovery answers two different questions, as robots-and-sitemaps explains. Confirm discovery points at the real sitemap:

$ curl -sS --max-time 20 https://www.xbcatm.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://www.xbcatm.com/sitemap.xml

Fetch the sitemap URL too and check canonical host and language URLs. robots.txt is crawler guidance, not access control; listing a URL in a sitemap does not guarantee crawling or indexing.

The whole path in one glance

Check	What to inspect	Note
`OPTIONS` status + Allow	observed method policy for this resource	http-method-semantics
`content-type` + body + `nosniff`	advertised type and MIME-handling policy	content-type-and-nosniff
HEAD/GET metadata	corresponding representation, with allowed omissions	head-parity
Range + Content-Range	observed partial-transfer support	http-range-requests
captured `ETag` -> 304	conditional representation match	conditional-requests
308 follows method	redirects preserve the story	redirects-and-status-codes
robots -> sitemap	discovery answers differ	robots-and-sitemaps

Each row was a note; now it is a command you can run against any edge. Read the linked note when you need the details, and keep this table as your re-check before you trust an endpoint.

Sources

WHATWG Fetch Standard, nosniff processing and request destinations, checked 2026-10-15.
RFC 9110 — HTTP Semantics, methods, validators, and status codes, checked 2026-10-15.
RFC 9111 — HTTP Caching, freshness and revalidation, checked 2026-10-15.
RFC 7538 — 308 Permanent Redirect, method-preserving redirect, checked 2026-10-15.
curl manual, read-only inspection flags, checked 2026-10-15.

Audit the trust of a public edge

Thu, 06 Aug 2026 00:00:00 +0000

The web-security series treats settings as contracts with scope and failure modes. This walkthrough inspects a host you are authorized to query. The HTTP, TLS, and DNS requests are read-only observations, although they still generate logs and traffic. SSH checks read your own trust record; the deployment host may differ from the website hostname.

Use a disposable local working directory for captured output. No output shown here is a fresh measurement of www.xbcatm.com, and a passing command proves only the property it actually checks.

Each observation supports a bounded claim. Header presence, certificate dates and local records cannot combine into a whole-service safety badge.

1. Start with the policy the edge advertises

Fetch a GET response without silently following redirects, then inspect its status and headers:

host=www.xbcatm.com
url="https://$host/"
curl -sS --max-time 20 -D headers.txt -o body.html "$url"
cat headers.txt

The repository’s intended policy includes the following illustrative fields:

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:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

script-src 'none' is a strict choice for this script-free site, not a universal recipe for every static site. The browser enforces CSP; a report-only header does not block execution. Read the complete policy for more-specific script directives, and compare normal pages and error routes. nosniff constrains MIME handling, notably script/style destinations, but does not certify the body’s media type.

HSTS is learned from valid HTTPS responses and applies to the host that sent it. A policy received from www.example.com with includeSubDomains covers descendants of that name, not its sibling api.example.com or parent example.com. Inventory the actual scope before adopting a long duration. A proxy adding or stripping headers changes the browser contract, which is why artifact checks and edge checks are separate.

2. Verify TLS identity before reading certificate dates

SNI selects the intended virtual host; it does not verify the certificate name. Make verification failure fatal and explicitly request hostname validation. Use an up-to-date trust store appropriate to the clients under test.

openssl s_client -connect "$host:443" -servername "$host" \
 -verify_hostname "$host" -verify_return_error -showcerts \
 </dev/null > tls.txt 2> tls.log
# Continue only if the command succeeded; preserve tls.log on failure.
openssl x509 -in tls.txt -noout -subject -issuer -dates -ext subjectAltName

Run these as separate checked steps, or under a shell setup that stops on failure. Hiding stderr or piping into a successful x509 command can conceal an unsuccessful handshake. Inspect the DNS names in subjectAltName; the displayed subject CN is not sufficient for modern service-identity validation. Some library versions retain legacy CN fallback, so explicitly check that the expected SAN is present. A valid matching wildcard may be legitimate; an unrelated certificate is not.

notAfter gives the expiry time. It does not prove the chain is trusted, the hostname matches, or revocation was checked. Record the date and the measured safety window rather than relying on memory. OpenSSL’s result describes its configured trust store and checks, not every browser’s behavior.

3. Read the presented chain without inventing a fixed count

The -showcerts output contains certificates sent by the server, not a declaration that they form a verified chain. This command displays their count only:

grep -c 'BEGIN CERTIFICATE' tls.txt

There is no required count of four. The server normally supplies the leaf and necessary intermediate certificates; a root usually belongs in the client’s trust store and need not be sent. Chain length varies with the CA and chosen path. One certificate warrants investigating whether intermediates are needed, but a count alone is neither success nor failure.

Use the actual verification result from step 2, then investigate issuer/SAN changes, missing intermediates, expiry, and trust-store differences. An intermediate rotation can be normal CA maintenance. A numerically unchanged chain can still be wrong, and the count command does not automatically compare anything with an expected value.

4. Revalidate the captured representation

Caching is a separate contract, not evidence of TLS identity. Capture a current ETag and use it on a request selecting the same representation, as in the HTTP walkthrough. A matching conditional GET can return 304; a deployment between requests can legitimately produce 200. An old hardcoded validator is not a reusable test fixture for a changing site.

A no-script policy does not mean CSP never changes. Security headers can change independently of HTML, and a body ETag does not fingerprint every response header. Record the actual policy again after release.

5. Find the relevant CAA policy

CAA constrains issuance by compliant certificate authorities. It is not certificate pinning and does not retroactively invalidate an already issued certificate. Start by inspecting the queried name and its ancestors; retain response status so a DNS failure is not mistaken for an empty answer.

dig www.xbcatm.com CAA +noall +comments +answer
dig xbcatm.com CAA +noall +comments +answer

An empty answer at www does not mean issuance is unrestricted. RFC 8659 searches upward until the first relevant nonempty CAA set, following aliases during each lookup; continue through applicable ancestors if necessary. Inspect issue, and issuewild when wildcard issuance is involved. An iodef report address alone does not restrict issuance. If no restricting policy applies, CAA adds no issuer restriction, but normal domain validation and CA rules still apply.

Compare the CA’s documented CAA identifier with the relevant policy, not merely the leaf’s human-readable issuer CN. Today’s CAA result is evidence about today’s DNS policy, not proof of what existed when the certificate was issued.

6. Check the deployment host’s recorded SSH identity

Use the actual SSH destination, including the bracketed host/port form for a non-default port. ssh-keygen -F can find hashed known-host entries that a text grep of the hostname misses.

deploy_host=deploy.example.test
ssh-keygen -F "$deploy_host" -f "$HOME/.ssh/known_hosts" > host-record.txt
ssh-keygen -lf host-record.txt

Compare the fingerprint with an independently trusted record, such as the provider console or a verified administrator channel. This reads the local record; it does not prove which key the remote host presents now. A network key scan alone would not authenticate that key either. Investigate a changed key before updating trust; a rebuild is one possible explanation, not automatic permission to accept it.

Inspect all Set-Cookie fields in the captured response and any relevant redirect or application route. No cookie on one page does not establish that the entire site never sets cookies. A host-only cookie omits Domain; adding a parent Domain broadens the hosts receiving it. Path controls delivery but is not a security boundary against same-origin code.

Secure restricts transport, HttpOnly blocks script access to the cookie, and SameSite controls specified cross-site sending behavior. They address different risks and do not replace one another; SameSite=None requires Secure in modern browsers. For this site’s no-account content model, ask why a cookie is needed at all before broadening its scope. Redact cookie values from shared audit records.

Keep a bounded audit record

Record the UTC time, client versions, requested/final URL, status, enforcing headers, TLS verification result and dates, relevant CAA lookup, and SSH record source. Distinguish observed success, unexpected results, and checks not performed. These several observations take more than “two commands” and cannot prove the whole service secure.

Repeat the relevant checks after certificate, DNS, proxy, or deployment changes. Preserve prior results to identify drift, and test actual browser behavior separately when the claim depends on browser enforcement.

Sources

WHATWG Fetch Standard, nosniff processing and request destinations, checked 2026-10-15.
OpenSSL s_client, SNI, hostname verification, fatal verification errors, and presented chains, checked 2026-10-15.
RFC 9525: Service Identity in TLS, SAN-based service identity and wildcard matching, checked 2026-10-15.
RFC 8659: CAA, relevant record-set search and issuance policy, checked 2026-10-15.
RFC 6797: HSTS, host scope and policy processing, checked 2026-10-15.
OpenSSH ssh-keygen, known-host lookup and fingerprint display, checked 2026-10-15.
W3C: CSP Level 3, enforcing versus report-only policy and script directive fallback (working draft), checked 2026-10-15.
MDN: Set-Cookie, cookie attributes and their limits, checked 2026-10-15.

Tutorial · XB Field Notes

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

Read a live edge the way a client does

1. Start with what a method may ask

2. Read the representation line

3. Compare HEAD and GET for the same representation

4. Ask for precise bytes with a range

5. Let the cache revalidate with a validator

6. Negotiate a smaller representation when you can

7. Follow the story when a URL changes

8. Let the crawler read the map last

The whole path in one glance

Sources

Audit the trust of a public edge

1. Start with the policy the edge advertises

2. Verify TLS identity before reading certificate dates

3. Read the presented chain without inventing a fixed count

4. Revalidate the captured representation

5. Find the relevant CAA policy

6. Check the deployment host’s recorded SSH identity

7. Keep cookie scope no broader than necessary

Keep a bounded audit record

Sources