Redirect-after-post

Problem

What becomes confusing, fragile, or impossible without understanding redirect-after-post? This lesson answers that through explanation, a worked example, two runnable exercises, and a reference solution. No teacher-supplied worksheet is required.

HTTP and hypertext scale by exchanging representations through standardized methods, status codes, headers, links, and forms.

Concept explanation

Redirect-after-post belongs to “Hypermedia controls state”. redirect-after-post is learned by comparing readable, constrained, and deliberately clever implementations against same evidence.

For redirect-after-post, trace concrete input, state transition, output, and failure through a request/response contract whose method, status, headers, representation, and next actions are observable.

A client sends a request; a server returns a representation plus metadata. Hypermedia controls advertise valid next actions. Apply that model to supplied normal, boundary, and failure cases; each case below names its input and expected evidence.

Example bank

Compare normal, boundary, failure, and cross-layer cases. Predict each observation before revealing the explanation.

Worked example

Start from supplied lab.sh. Focus: Solve redirect-after-post three ways using identical fixture: Build three server-rendered states connected only by links and POST forms.

1. Run: chmod +x lab.sh && ./lab.sh
2. Save baseline evidence. Compare curl -v output, request method, status, cache metadata, redirects, and representation bytes.
3. Boundary case: Run all three implementations against: Disable JavaScript and complete full workflow.
4. Failure case: Force every implementation through: Submit invalid transition and return useful 4xx representation with recovery link.

RESULT
All versions preserve Every state exposes next valid actions; refresh after POST does not duplicate mutation; failure remains navigable.; comparison records code size, predictability, and debugging cost. Starter-level baseline: headers.txt begins with an HTTP status line; body.txt contains the representation; byte count is greater than zero.

Starter material

Create lab.sh, paste this exact content, then run the command below.

#!/usr/bin/env sh
set -eu
url="${1:-https://example.com/}"
printf '%s\n' '# redirect-after-post'
curl -sS -D headers.txt -o body.txt "$url"
sed -n '1,12p' headers.txt
printf 'body bytes: ' && wc -c < body.txt

STOP / CLEANUPNo background process. Remove headers.txt and body.txt only after saving evidence.

Independent exercise

Compare three versions: redirect-after-post

1. Create second case from blank file: Run all three implementations against: Disable JavaScript and complete full workflow.
2. Then create controlled failure: Force every implementation through: Submit invalid transition and return useful 4xx representation with recovery link.
3. Use curl · Chromium Network · server logs to prove behavior, then repair controlled failure.
4. Compare result against supplied acceptance checks and reference approach before marking complete.

Expected result

• All versions preserve Every state exposes next valid actions; refresh after POST does not duplicate mutation; failure remains navigable.; comparison records code size, predictability, and debugging cost.
• headers.txt begins with an HTTP status line; body.txt contains the representation; byte count is greater than zero.
• Controlled redirect-after-post failure produces captured evidence; repair restores stated invariant without hiding error.

Hints

Solution

Attempt both exercises before opening reference approach.