Search

A request method changed after a redirect

Trace the redirect status and follow-up request before changing client or server behavior.

Difficulty
intermediate
Published
July 13, 2026
Last reviewed
Review due
  • redirects
  • methods
  • diagnostics

Diagnostic overview

Symptoms

  • An origin expects POST but receives GET after a client follows a redirect.
  • Request content disappears between the original and redirected request.

Likely layers

client, proxy, cdn, origin, protocol

Common causes

  • A 301 or 302 response triggers permitted historical POST-to-GET behavior.
  • A 303 intentionally directs the client to retrieve another resource with GET.
  • A framework emits a default redirect code that does not match the intended method semantics.

Diagnostic steps

  1. Capture the original request and redirect response without following.

    Look for: The exact status identifies the permitted follow-up semantics.

  2. Capture the next request separately with sensitive values removed.

    Look for: Its method, target, and content show what the client actually preserved.

  3. Identify which application or intermediary emitted the redirect.

    Look for: The responsible configuration reveals whether rewriting was intended.

Targeted fixes

  • Use 303 when the follow-up is intentionally a retrieval.
  • Use 307 or 308 when automatic following must preserve method and content.
  • Avoid replaying a non-idempotent request automatically without an application-safe retry contract.

Capture both exchanges

Do not infer method handling from the final page. Record the redirect response and the follow-up request as separate exchanges.

HTTP/1.1 301 Moved Permanently
Location: /orders/current

Expected result: a user agent is allowed to change a POST to GET while following this 301. The status does not require preserving the original content.

Choose the intended semantics

Use 303 See Other when processing is complete and the next action should be a GET. Use 307 Temporary Redirect or 308 Permanent Redirect when method and content must be retained.

Verify replay safety

Preserving POST can repeat an operation after partial failure. Confirm the application’s idempotency or deduplication contract before enabling automatic retries or redirect following for non-idempotent requests.

Primary sources