Your Redirect Succeeded. Did the POST Body Reach the API?

When a curl-based migration probe returns HTTP 200 OK after following redirects, it can be easy to assume the POST succeeded as intended. In practice, however, an automatic redirect often means the original request was not delivered as sent. In our owned lab environment (Python 3.13.5 and curl 8.10.1 on POSIX), we intentionally test a JSON POST with a unique request_id and newline. We compare the exact raw payload (bytes and SHA-256 digest) at each hop versus the final endpoint. This lets us determine whether each redirect actually forwarded the original POST body or not. Only if the terminal /sink sees the same method, ID, and byte-for-byte payload do we consider the write contract satisfied. Before accepting a write-endpoint migration, we must align documented redirect semantics with our actual observations, and collect concrete evidence per hop. This review then leads to one of four decisions: ACCEPT if the method+body contract held; REPAIR if a configuration fix is needed; HOLD if an untested client, missing trace, or policy gap exists; or RECONCILE if an earlier incomplete attempt requires manual resolution.

This article walks through that acceptance-and-repair playbook step by step. We declare the intent of each test (retrieval vs migrated write), detail our curl invocation (with all flags to isolate behavior), and show how we capture a ledger of each server-side request record. For each redirect code (301, 302, 303, 307, 308) and special flag (--post302 or -X POST), we compare the expected HTTP semantics with the observed result. Throughout, we cite RFC 9110 and the curl documentation for how redirects “may” work, and distinguish that from how our curl behaved (which we verify). We then summarize all cases in a table of hops, and conclude with a decision matrix (evidence, owner, next steps). Finally, we discuss how to turn this review into a repeatable API practice, linking to key APIs Developer Fundamentals training concepts.

Declare whether this redirect is a retrieval or a migrated write

The first step is to interpret the scenario: Is this redirect intended as a read (e.g. a receipt or status URL) or as a write forward? In a migration, we want the former endpoint’s business logic to be invoked on a new URL, preserving the POST and its body. In contrast, after a successful write you often see a receipt or redirect to a different resource (the Post/Redirect/Get pattern) where the subsequent request is purely a fetch.

For clarity, label roles: the client owner controls how curl is invoked, the server owner controls the redirect code and target. The key aspects to define before the test are: the HTTP method (POST), the content (a synthetic JSON with request_id and newline), the intended destination URL (the new endpoint). We include a custom header X-Lab-Request-ID with the same ID, so the final /sink response can echo it back. We explicitly decide in advance whether the redirect is meant to carry the write forward or simply deliver a receipt. For example, if the redirect is meant to fetch a receipt, changing POST to GET is semantically correct (and we would not insist the body survive). If it’s a migration of the write itself, then method+body must be preserved. This step distinguishes a simple retrieval of a receipt (acceptable with a 303 GET) from a true endpoint migration where the POST must reach the new URL.

This exercise assumes we own both sides of the loopback test, so we label the IDs and assert the correct finish. Before running curl, we ensure the scenario is unambiguous: the POST has not already been committed on the original server, and we want to “teleport” it to a new one. In the lab fixture below, the handler at /r/{code} will immediately redirect to /sink. If we are testing a write-migration (for a code 307 or 308), we expect /sink to receive the POST and body. If the redirect code is 301/302/303, we note that HTTP allows a method change (to GET) by default, so if curl does change to GET, that is expected by protocol, but would fail our stricter migration contract. We record this intent and inspect actual behavior carefully.

For real APIs, the decision (read vs write) must come from design documentation or conversations with the server owner. For example, redirecting to a receipt might be documented as “this resource returns 303 after creation,” whereas a permanent API move should use 308 or an explicit “302 but keep method” directive. Without explicit specification, we treat any body loss as a failure of a migration contract, even if HTTP semantics technically “allow” it. This mindset of aligning written behavior with protocol permission is a key part of API design and validation foundations. API design documentation should explain proper status codes and contracts.

Pin the client and isolate the two-hop fixture

Before testing redirects, lock down the client environment. We run this on a single POSIX machine with Python 3.13.5 and curl 8.10.1 (the exact outputs are from this build). To avoid hidden settings, start each curl with -q (no ~/.curlrc), use --noproxy '*' to ignore any proxy variables, and set explicit limits: --max-time 5 seconds timeout, --max-redirs 3 so it never follows more than 3 hops. We also restrict protocols with --proto '=http' --proto-redir '=http' to avoid HTTPS or other schemes. These flags ensure curl’s behavior is fully driven by our command line, not by user configs or environment.

Our two-hop fixture is an in-memory HTTP server (bound to localhost on an ephemeral port) that handles any path. If the path matches /r/{code} where {code} is one of 301, 302, 303, 307, 308, it will respond immediately with that status and a Location: /sink header (no body). If the path is /sink, it will respond 200 with a JSON body echoing the last request’s details (path, method, headers, body length, SHA-256 of body). We then invoke curl on http://127.0.0.1:{port}/r/{code} for each case. A direct POST to /sink (no redirect) is also one case.

Here is an example of invoking curl for the direct and 307 cases (simplified):

# Prepare a JSON body with newline.
echo '{"request_id":"direct","value":7}'$'\n' > body.json

curl -q --silent --show-error --noproxy '*' \
  --max-time 5 --max-redirs 3 \
  --proto '=http' --proto-redir '=http' \
  --header 'Content-Type: application/json' \
  --header 'X-Lab-Request-ID: direct' \
  --data-binary @body.json \
  --output reply \
  --dump-header headers.txt \
  http://127.0.0.1:{port}/sink

# For a 307 redirect test:
echo '{"request_id":"L307","value":7}'$'\n' > body.json

curl -q --silent --show-error --noproxy '*' \
  --max-time 5 --max-redirs 3 \
  --proto '=http' --proto-redir '=http' \
  --header 'Content-Type: application/json' \
  --header 'X-Lab-Request-ID: L307' \
  --data-binary @body.json \
  --location \
  --output reply \
  --dump-header headers.txt \
  http://127.0.0.1:{port}/r/307

Each invocation uses --data-binary @body.json to send the raw file. The --location (or -L) flag is used in redirect cases to follow the Location: header. We capture the response headers in a file (--dump-header) and the response body in reply. The server’s logic guarantees it reads the entire request body (Content-Length specifies it), computes its hex and SHA-256, then if redirecting sends a zero-length response, otherwise if at /sink it replies with JSON of the received record. This double-checks that the server saw the payload.

Control ambient options before interpreting a redirect

We emphasize again: do not rely on any implicit settings. Using -q and --noproxy '*' isolates curl from config or environment changes. Always set explicit limits: here we use --max-redirs 3 (overriding curl’s default of 30) to make the test bounded. By default curl will silently stop at 0 redirects (no -L), so adding -L is essential to follow the hop when desired. We also avoid --location-trusted since that is irrelevant for localhost. If any curl returns a nonzero exit code, we treat it as a “HOLD” in our matrix.

This strict setup ensures our observations reflect only the redirect logic, not any higher-level caching or proxy behavior. (In real deployments, other factors like authentication or cross-origin credentials might interfere, but we exclude those here.) In short, we’ve pinned down the client so that any change in outcome is due solely to how curl implements the HTTP redirect and our flags.

Create independent request and destination evidence

To validate delivery, we must capture both what left the client and what arrived at each hop. The JSON body fixture is simple: a single object with a unique request_id and value, plus a trailing newline. For example:

{"request_id":"XPOST302","value":7}

The payload includes a trailing \n. We compute its length and SHA-256 hash ahead of time.

Our server’s handler builds a ledger entry for each request, recording:

• path (the URL path, e.g. /r/302 or /sink)

• method (GET or POST as seen by the server)

• request_id header (our injected test ID)

• body_hex (hex-encoded request body seen, empty if none)

• bytes (length of body)

• sha256 (digest of body)

For example, after a POST to /sink, the ledger might contain:

{
  "path": "/sink",
  "method": "POST",
  "request_id": "direct",
  "body_hex": "7b22726571756573745f6964223a22646972656374222c2276616c7565223a37207d0a",
  "bytes": 28,
  "sha256": "4f29a0f71bb3f0..."
}

This record is then dumped back in the 200-OK response from /sink.

Importantly, we store every hop’s record, not only the final one. This means if there is a redirect step /r/301, we will have a ledger entry for the original POST to /r/301 and then (if followed) an entry for the subsequent GET or POST to /sink. Keeping the full history lets us compare requests hop by hop. The client-side captured headers file and output JSON allow us to cross-reference timing and hops with the ledger.

With these pieces, our oracle is: the final ledger entry at /sink should have method: POST, the same request_id, and a body_hex matching exactly the original file. We also verify the bytes and sha256 match. Any discrepancy means the POST body was not delivered unchanged. This hop-by-hop evidence gathering (capture request, redirect, final) is our proof for each test case.

Observe POST becoming GET after 301, 302 and 303

We now run curl with -L for the 301, 302, and 303 cases. By default HTTP semantics (RFC 9110), 301 and 302 “allow” changing POST to GET, and 303 explicitly mandates a GET retrieval of another resource. In practice curl and browsers historically do switch to GET for these codes. Our fixed fixture shows:

• L301 (curl --location to /r/301): The server receives first a POST to /r/301 (with the body), then responds 301 with Location: /sink. Curl then follows to GET /sink with no body. Ledger shows final method: GET, empty body_hex, and no request_id (because we only set it on POST). The returned JSON in reply is the record for the GET request (which has no body). Thus no body is delivered to /sink.

• L302 (curl -L to /r/302): Similarly, the first POST is sent and seen, then curl follows with GET to /sink. Final ledger has GET/no-body. This matches curl’s default policy: GET after 302. (As everything curl explains, 302 historically acts like 303 here.)

• L303 (curl -L to /r/303): Again, the first POST is seen, then curl follows with GET (curl treats 303 like 302) and /sink sees method GET, no body.

In each of the above, the terminal HTTP code is 200 (from /sink) and curl’s output code is 0 (success), but the body is dropped. We compare this to RFC 9110 §15.4.3-15.4.4, which says clients may switch to GET on 301/302, and must use GET on 303. Our observed curl 8.10.1 indeed did GET in all three cases. This loss of body is not a network error; it is allowed by the protocol as designed, but it violates our stricter API contract of “the POST must go through.” Thus for a write-migration, all these cases fail our contract.

A documented permission is not identical behavior in every client

It’s important to note that the RFC language around 301/302 is permissive. That means some clients could have kept POST, but browsers and curl traditionally do not. In summary:

We separate the permission (RFC allows it) from the default (curl actually did it). For example, RFC 9110 §15.4.2 (301) and §15.4.3 (302) note that, if the original was POST, a client “might” follow with GET or re-POST, but that latter is nonstandard; most switch to GET for “historical reasons”. As everything curl explains, curl follows browsers’ lead by default, turning any POST into GET after 301/302/303. Our experiment confirms that curl 8.10.1 did exactly that: the ledger entries for L301, L302, L303 end with method: GET and body_hex: "".

We emphasize: curl’s observed behavior matched the RFC’s permitted behavior, but not necessarily the RFC’s ideal of “MUST re-post” (which is only required for 307/308). This distinction matters because some API documentation might say “this endpoint returns 301 but expects a POST to be re-sent”; but actually curl won’t do that unless specifically instructed. In short: a documented MAY change to GET means “it happens in practice,” and we must explicitly override if we want otherwise. Without --post302 or similar, our test results for 301/302/303 were GET and empty-body (request contract false). These cases cannot be accepted for migrating a POST body without further action (HOLD or REPAIR below).

Compare the 307 and 308 preservation cases

Next, we test the two “method-preserving” redirect codes. By design, HTTP 1.1’s 307 (Temporary Redirect) and HTTP/1.1’s 308 (Permanent Redirect) promise “keep the method and body” in the next request. In our fixture both respond with Location: /sink.

Using curl -L to follow:

• L307 (curl -L to /r/307): The server sees a POST to /r/307 with our body (captured). It responds 307 to /sink. Curl then replays the same request: method POST, same headers, and crucially the same body file. The ledger entry for /sink shows method: POST, body_hex exactly matching the original, bytes: 28. SHA-256 hashes match. This is the correct contract-preserving behavior. The response is 200 with JSON echo containing the original record. curl saw 200 and the output JSON shows our body went through. We marked this contract “accepted.”

• L308 (curl -L to /r/308): Likewise, the 308 triggers curl to repeat POST exactly. Final ledger: method POST, body intact, ID present. Contract “accepted.”

These results confirm that for codes 307 and 308, curl honors the semantics: it does not switch to GET, but sends the original POST. (MDN notes “the method and body of the original request are reused” for 307.) Our ledger proved byte-for-byte equality of the body in the final hop for L307 and L308.

We double-check with hashes to be certain: both cases show identical SHA-256 to the input file. In summary:

This matches HTTP semantics. In migration terms, these two cases meet the contract: the POST successfully arrived at /sink unchanged. We therefore accept these scenarios (subject to other concerns; see decision matrix). It’s worth noting 308 is a relatively newer code (RFC 9110 updated it), but our curl behaved correctly. We did not find any caching or “permanent” effect beyond one request; curl treated 307 and 308 the same for a single redirect.

Show why forcing the POST token is not a body repair

To test curl’s flexibility, we try a “negative control”: use -X POST with a 302 redirect. That is, instead of letting curl change to GET, we force the second request to be POST by resetting the method token. In our fixture:

• XPOST302 (curl -L -X POST to /r/302): Curl still follows the redirect, and the final request is marked as POST (per the override). However, our ledger shows the body is empty on the second hop. In other words, curl sent a POST request to /sink without the original payload. The first hop was POST with body (so body sent once), but on redirect, the -X POST simply changed the label “POST” but did not re-send the data. The ledger for /sink has method: POST but body_hex: "" and bytes: 0. This case is contract-failing even though the method token is POST.

In more detail: The HTTP request log shows “POST /sink HTTP/1.1” but no Content-Length header (since no data was sent the second time). It’s a common misunderstanding that -X POST is a “fix” for redirects. It is not: -X only sets the request verb, not the body. In our experiment, forcing POST left an empty write. This highlights: do not trust the client-side method label without verifying body bytes.

MDN explicitly warns: 307 guarantees method/body, 302 does not; using 303 changes to GET; but there is no built-in way for 302 to keep the body unless using curl’s --post302 option (see next). The -X POST trick is insufficient. We see this difference:

L307: POST 28 bytes (accepted)
post302 (--post302): POST 28 bytes (accepted)
XPOST302 (-X POST): POST  0 bytes (lost)

Thus bytes matter more than the method token. Even if curl logs “POST” for the second request, the payload must be checked. In practice, any API design or migration test must compare bodies. We use the ledger’s body_hex or digest to confirm. This is why our criteria rely on exact byte equality, not just “method was POST.”

Compare bytes rather than trusting a method label

The above shows an essential rule: verify the payload, not just the HTTP verb. We compute SHA-256 on the raw body for each ledger entry. For XPOST302, the digest of the first POST was non-zero, but the final /sink digest was that of an empty string. If we only looked at method=POST, we’d be deceived. Our fixture’s JSON reply for XPOST302 clearly shows no data in the final POST:

{
  "path": "/sink",
  "method": "POST",
  "body_hex": "",
  "bytes": 0,
  "sha256": "e3b0c44298fc1c..."
}

This mismatch triggers a FAIL on our contract check. In short, trusting the verb without the payload would be a mistake. We highlight this as a caution: always compare full request bodies (or digests) when evaluating redirects.

Test an explicit client override without changing the server contract

Curl provides a special flag --post302 (also --post301 and --post303) that does instruct it to re-send the POST on redirects. This does not change the server’s redirect behavior, but tells the client to act differently. We test:

• post302 (curl -L --post302 to /r/302): The first request is POST (with body), and on the 302 redirect, curl now repeats the POST with body. The ledger shows the final /sink received POST and the correct payload. The metadata confirms request_contract = true. The response JSON matches L307/L308 in that the body was delivered.

So --post302 is a curl-only override for the nonstandard case of “I want to keep POST on 302.” It fixes the problem client-side. But note: this only affects this instance of curl. Browsers and other tools would still lose the body (unless they implement something similar). In particular, it does not tell the server to change anything; the response code is still 302. It simply persuades our curl test to pretend 302 was like a 307.

Operationally, this means: if the server owner cannot or will not send 307/308, the client owner could apply --post302 as a targeted workaround. However, this is a client-specific hack. We must document that every integration (e.g. any script, service, or browser automation) must also adopt this flag to maintain the contract. For example, this will not help a browser’s native fetch. Use of --post302 is not visible to outside clients. It’s effectively the client owner acknowledging “I know 302 is here, I’ll override it on my side.”

In his HTTP redirects guide, Daniel Stenberg explains that --post302 keeps the next request as POST after a 302 response. The outcome of our post302 case matches exactly: final POST, body present. We conclude: --post302 works, but treat it as a narrow tool: acceptable if you control the client code and know only curl is in use. It’s not a universal protocol fix.

Keep a valid 303 receipt flow out of the migration repair

One scenario we must deliberately exclude from migration semantics is the classic “Post/Redirect/Get” flow. A 303 See Other is often used by servers to indicate “go fetch your receipt here” via GET. Changing that to POST would break the intended workflow. In our fixture, if the server uses 303, it is presumably signaling that the POST is complete and the client should use GET to retrieve something (maybe a status or receipt).

Thus, we treat 303 redirects as separate flows: the original POST is done at the first endpoint (which in our lab just did an immediate redirect) and the GET to /sink is purely a read. For example, if we deliberately disable following (to simulate a client not obeying redirect), the lab shows:

• no_follow (a POST to /r/302 with no -L): Curl sees 302 and stops. The exit code is 0, but the http_code is 302. We have one hop (the POST to /r/302) and the ledger entry shows the body was received by /r/302, but we never sent anything to /sink. This case clearly fails (and we mark no-follow as a HOLD: no terminal confirmation).

• For L303 (with -L): we already saw curl did POST then GET. But in a proper design, the POST would have side-effects (or have been consumed by /r/303), and /sink would only get a GET to fetch the result. If this 303 was intended to be a receipt, then the GET’s emptiness is fine, because the business logic at /r/303 already did what it needed.

The key point: if a 303 was intended as the final step of a write operation, don’t try to make the GET look like the write itself. We should not attempt to change the server’s 303 to 307 just to get the body to /sink. Instead, we identify whether the original write actually occurred at /r/303. If so, then the GET to /sink was not supposed to carry a payload. In this lab, our server code was not performing any backend action; it just prints a 303 and moves on. In real life, the “destination” of a write is ambiguous: possibly the original URI (that gave 303) already did the work.

Therefore, for 303 (and by extension, patterns where a redirect is clearly meant for a retrieval), we exclude these from our migration acceptance table. We classify them as “receipt style” by context (e.g. URL path or API docs). They are correct if /r acted on the write, and the redirect to GET is only giving a view. If an API wanted a pure migration instead, it should have used 307. We label “do not replay a completed write at its receipt URL” as policy: do not change the server’s 303 to POST or treat it as missing a body.

In practice, we handle this by aligning on intent first. If the redirect code is 303 and we know this is a PRG pattern, we would simply verify that the GET response is a valid confirmation page, not require that /sink see the original JSON. The test for a receipt flow would be: did the first endpoint receive a POST and do something? That requires separate checks (outside this lab) on the original /r/303 handler. If that is uncertain, we can’t blindly rewrite it. We must likely mark that case as needing reconciliation (see below).

For completeness, our fixture’s L303 case (with -L) ended up with GET/no-body to /sink, so we would not mark “accepted” because this was not a migration of the body; rather, it’s a valid PRG GET. So we say: this case is a correct receipt retrieval, and should not be “fixed” into a migration. This highlights that not all passing table entries are suitable for migration; PRG flows pass under their own contract.

Build a hop-by-hop acceptance table

Collecting our observations yields this summary of all nine cases (exit code, final HTTP code, hops, final method, body match, and our acceptance of the contract). For brevity we encode contract as PASS/FAIL for “did body reach correctly at /sink?”:

• Hops: direct has 1 hop (no redirect). L301/302/303, L307/308, post302, XPOST302 each have 2 hops (original + follow). no_follow has 1 (stopped at 302).

• Body Preserved: We mark “Yes” only when final /sink body matches. L301/L302/L303/XPOST302 fail that.

• Contract Accepted: Only direct, L307, L308, post302 passed our strict check. L303 is a separate receipt flow (we don’t mark it as a migration success or failure).

• no_follow: is clearly a failure because it never even delivered to /sink; we get 302 back.

From this table, four cases satisfy our write-delivery contract. The others did not; they either lost the body or never ran it at /sink. Even if curl exit=0 and http_code=200 (for all with -L except no_follow), the real check is body_preserved.

Repair the endpoint transition at its actual owner

Given the failing cases, what do we do? The answer is: fix at the source of mismatch, which could be the server’s redirect code or our client’s configuration. We list options:

• Server fix (PERMANENT): Change the redirect code to one that preserves POST for API calls. For example, if the server currently responds with 302, it could instead use 307 (Temporary redirect) or 308 (Permanent). A 308 is best if this URL move is permanent. That way any standard client (curl, browser) will automatically keep the POST. This is a server-side code or config change. It is “reversible” by reverting the redirect status back to 302 or original mapping.

• Client fix (overrides): If changing server code is not feasible immediately (e.g. in a phased rollout), apply curl --post302 in the client’s migration script. This only affects curl invocations. The owner of the integration must update any scripts accordingly. This is typically a short-term fix.

• Combined / scoped fix: Possibly configure the specific endpoint via a location header directive (some servers allow specifying “preserve method” on redirects) or use an intermediary like an API gateway to remap. However, adding auth-forwarding or proxying (excluded topics) is more complex.

We do not suggest client solutions like -L vs --post302 for browsers, because those do not exist uniformly. Nor do we suggest global proxy rewrites that might affect other APIs. The choice depends on ownership: if you own the server code, prefer a 308. If only the client is under your control, --post302 is a patch.

We record this as: REPAIR action for the failing cases (L301/L302/L303/XPOST302). For example, a server developer could change status 301 or 302 to 308 for that endpoint (or 307 if temporary). As a reversible approach: keep the old URL in service until cutover, and when rollback is needed, restore the original status. (Repair is deploying code, not deleting data.)

Make the repair reversible without erasing prior effects

Important: a rollback of the redirect code should not try to undo any business operations. The repair is purely about routing. For instance, if some requests made it through to the old endpoint before the fix, their effects are in the backend. The fix shouldn’t erase them; it just changes where new requests go. Conversely, if we roll back to the old endpoint, it means new POSTs will go back there (still possibly doing the same write), but again, we do not attempt to “undo” anything. The ledger of request_ids is kept so we don’t lose track of what already happened. In short, make infrastructure and client-route changes reversible, but treat each business write as one-way (not automatically reversible).

Reconcile uncertain earlier requests before repeating them

If any request did not see the body at /sink, that means the desired write may or may not have occurred at the original location. We must not blindly retry or replay the POST. For example, if we sent a POST to /r/302 and then lost the body, did /r/302 actually process it? In our test, /r/302 immediately redirected with no processing, so nothing happened. But in a real API, maybe /r/302 did record or partially commit something before issuing the redirect.

Therefore, before trying again, we need reconciliation. We saved each X-Lab-Request-ID header. In a real system, use idempotency keys or audit logs to check the fate of that ID at the original endpoint. If the original acted (e.g. returned a receipt, stored data, etc.), do we need to do anything? If it did nothing (as in our lab), a retry of the POST at the new endpoint may be safe. But in general, the owner of /r/ should confirm whether the operation was completed. This might involve querying the database or logs for that request_id.

If it’s uncertain, the safe path is HOLD: pause and manually reconcile. Create a compensating process outside of curl. This could be a manual confirm of what happened at /r. Only once we know the original write is either done or not should we proceed. In other words, our testing ladder has shown the deficiency, but the decision to actually re-submit the data (if needed) is a separate “business reconciliation” step that we do not automate in this test. We mention this step here to ensure teams do not repeat POSTs blindly, possibly causing duplicate side-effects.

Rerun the regression matrix on the deployed client configuration

Any fix (client or server) must be verified in situ. That means re-running similar tests with the actual deployment’s curl (or other clients, if applicable). For every supported client version (and script language), repeat the exact matrix of cases: direct, all redirects with and without overrides. Record versions (curl --version), OS info, and any differences in output. For example, after upgrading curl or moving from one HTTP library to another, behavior might change (especially across major versions).

Document each test run: command-line used, environment details, and the hop ledger. Compare against our reference outputs. If a result now differs unexpectedly (say a newer curl version changed its default), do not simply update the acceptance criteria. That should be a HOLD condition. Investigate why, update your policy if agreed, but treat it as an anomaly until reviewed.

Hold any unsupported or unexplained client result

If any client (e.g. a particular build of curl, wget, or a REST client) does not match the expected behavior, we pause. The safest stance is to HOLD that build: don’t assume it meets the contract or skip testing it. Capture the version and output (<client> --version and test logs). For example, some older curl might not even have --post302, or a security-hardened HTTP library might reject mixed-method redirects. We require fresh evidence on every variant. In our case, curl 8.10.1 passed nine tests successfully. If another user ran redirect_lab.py on a different version and got a different result, that build would be marked HOLD until understood. This keeps our migration policy strictly backed by traceable evidence.

Choose ACCEPT, REPAIR, HOLD or RECONCILE

We now summarize the decision logic. Each request (identified by its request_id) falls into one of these final categories:

• ACCEPT: The final ledger shows method: POST at /sink with the correct request_id and matching body bytes. The evidence (exit code 0, final HTTP 200, hops count, payload hash) all align. When accepted, no further action is needed for that request itself; it completed the POST as intended. Ownership: developer/team of the new endpoint. Action: proceed with migration, keep record of success. Stop when entire test matrix passes. (Example: direct, L307, L308, post302 here.)

• REPAIR: A fix is needed in configuration/code. Ownership: either server team (if wrong redirect code) or client team (if needing --post302). Action: implement 307/308 or add flags. After repair, retest. Mark any replaced requests (by new request_id) as requiring a fresh acceptance test.

• HOLD: A client or configuration issue is unresolved. Ownership: the team responsible for that client/tool. Action: obtain correct binary/build (or disable unsupported option) and rerun tests. For example, if a newer curl unexpectedly switches GET→POST differently, keep it in HOLD until sorted.

• RECONCILE: The request possibly had side-effects at the original endpoint but not confirmed at the destination. Ownership: operational/QA team. Action: check logs or data store for the original request_id. Decide if the operation already succeeded; if not, decide whether to replay the POST manually or not. Stop condition: resolution of ambiguity.

These decisions align with DevOps release validation principles: each change is tested, documented, and either rolled out or rolled back with clear evidence. For example, a minimal decision table:

In all cases, we do not implicitly clear the database or change server state. “Accept” means the request can be considered delivered; if further business processing is required (de-duplication, commit, etc.), that’s separate.

Turn request-contract review into a repeatable API practice

Finally, integrate this kind of redirect testing into your team’s workflow. Capture the scripts, inputs, and outputs (e.g. curl commands and the resulting JSON) as evidence for code reviews or release notes. Periodically retest, especially when upgrading clients. Document in your API spec: “Note: this endpoint now permanently responds with HTTP 308, so client must preserve method and body on redirect,” or vice versa. Use these exercises to validate that endpoint migrations won’t silently drop data.

This procedure aligns with the principles taught in our APIs Developer Fundamentals program, where we emphasize reliable API design, testing, and versioning. Recall that our training covers designing APIs with correct status codes and error handling, as well as hands-on migration testing. By practicing these steps, you build confidence that an endpoint move truly delivered your POST payload and that any redirect behavior is explicit and intentional. (The curriculum also recommends using tools like curl and writing automated tests for exactly this kind of check.)

One practical tip: automate your command invocations (as we did in the Python fixture). That way, each new deployment can trigger the same matrix. Include the request_id in your CI/CD logs, so any discrepancy stands out. When all nine curl tests pass as intended, you can ACCEPT the migration. If not, refer to this playbook to REPAIR, HOLD, or RECONCILE as needed, using documented evidence at every step.

By treating redirect behaviors as part of your release validation within the DevOps lifecycle, you turn a tricky protocol quirk into a manageable test case. And remember: use a distinct POST body and checksum like we did; never assume a redirect “just works” without verifying. With these precautions and checks in place, you can confidently answer “Yes, the POST body reached the API”, or know exactly what to fix if it didn’t.

About Refonte Learning APIs Developer Fundamentals Program: The 3‑month program (10–12 hours/week) covers API design, testing, error handling, logging, and versioning. It recommends basic programming and a college degree, and culminates in a certificate. Many graduates apply these skills in real projects and internships. For more, see the APIs Developer Fundamentals page (study schedule, curriculum, and mentoring details).