HTTP 302 vs 307: Temporary Redirects Explained

Intermediate

Temporary redirects in HTTP come in two primary flavors: 302 Found and 307 Temporary Redirect. While both tell the client that a resource has temporarily moved to a different URL, they differ in a critical way that affects form submissions, API calls, and HTTP method handling. Choosing the wrong temporary redirect can cause silent data loss when POST requests are converted to GET, or confuse search engines about which URL should appear in results.

The distinction between 302 and 307 exists because of a historical mismatch between the HTTP specification and actual browser behavior. Understanding this history explains why HTTP/1.1 needed to introduce two new redirect codes (303 and 307) to fix the ambiguity in 302.

Why Were 307 and 303 Created to Fix 302?

HTTP/1.0 (RFC 1945, 1996) defined 302 as "Moved Temporarily" with clear semantics: the client should use the new URL for this request only, and the request method should not change. A POST to /submit that received a 302 redirect to /result should POST to /result.

However, early browsers — Netscape Navigator and Internet Explorer — implemented 302 differently. When they received a 302 after a POST request, they changed the method to GET before following the redirect. This behavior became so widespread that fixing it would break existing websites. The HTTP/1.1 specification (RFC 2616, 1999) acknowledged this reality by noting that "many existing user agent implementations treat 302 as if it were a 303 response."

To resolve the ambiguity, HTTP/1.1 introduced two new codes:

• 303 See Other — always changes the method to GET (formalizing what browsers actually did with 302)
• 307 Temporary Redirect — strictly preserves the original method (what 302 was supposed to do)

Similarly, 308 Permanent Redirect (RFC 7538, 2015) was introduced as the method-preserving version of 301. Together, these four codes form a complete matrix:

How Does HTTP 302 Found Work in Practice?

A 302 response tells the client that the resource temporarily resides at a different URL. The client should continue using the original URL for future requests. In practice, browsers treat 302 almost identically to 303 — converting POST requests to GET when following the redirect.

HTTP/1.1 302 Found
Location: https://example.com/temporary-page
Cache-Control: no-cache

Common use cases for 302 redirects include:

• A/B testing — temporarily routing a percentage of users to variant pages
• Geo-redirects — sending users to country-specific versions of a site based on IP geolocation
• Maintenance mode — temporarily redirecting all traffic to a maintenance page
• Promotional campaigns — temporarily redirecting a URL to a seasonal or event-specific page

For each of these, the original URL will eventually serve content again, making a temporary redirect the correct choice. Using a 301 permanent redirect in these situations would cause browsers to cache the redirect permanently, making it difficult to revert when the temporary condition ends.

How Does HTTP 307 Temporary Redirect Differ?

The 307 status code has one strict guarantee: the request method and body are preserved when following the redirect. If the client sends a POST with a JSON body to /api/submit and receives a 307 redirect to /api/v2/submit, the client must POST the same JSON body to the new URL.

This matters for API endpoints, payment processing flows, and any form submission where the server needs to receive the original POST data at the redirect target. With 302, the POST data would be lost because browsers convert the method to GET.

HTTP/1.1 307 Temporary Redirect
Location: https://api.example.com/v2/submit

Use cases specific to 307:

• API version migration — temporarily routing API requests to a new endpoint while preserving request method and body
• HTTPS enforcement — redirecting HTTP POST requests to HTTPS without losing the POST body (though HSTS is preferred)
• Load balancing overflow — temporarily routing requests to a different server while preserving the full request

What Is 303 See Other and the PRG Pattern?

HTTP 303 See Other explicitly tells the client to retrieve the redirect target using GET, regardless of the original request method. This is the correct code for the Post/Redirect/Get (PRG) pattern — a common web development technique that prevents form resubmission on browser refresh.

The PRG pattern works as follows:

1. User submits a form (POST to /order)
2. Server processes the form and responds with 303 → /order/confirmation
3. Browser follows redirect with GET to /order/confirmation
4. If user refreshes the page, the browser repeats the GET (not the POST), preventing duplicate orders

How Do CDNs Handle Temporary Redirects?

CDNs treat temporary redirects differently from permanent redirects. By default, 302 and 307 responses are not cached at CDN edge servers. Each request for the URL generates a new request to the origin server, which determines the redirect dynamically.

This default behavior is correct for truly dynamic redirects — geo-routing, A/B testing, or user-specific redirects where the destination varies per request. However, for semi-static temporary redirects (like a maintenance page that applies to all users), you can enable CDN caching by including explicit cache headers:

HTTP/1.1 302 Found
Location: /maintenance
Cache-Control: public, s-maxage=300
Vary: Accept-Language

The s-maxage=300 tells CDN edge servers to cache this redirect for 5 minutes, while Vary: Accept-Language ensures that the CDN maintains separate cached versions for different languages — important for internationalized redirects.

Be cautious with Vary headers on redirect responses. A Vary: Cookie header effectively disables CDN caching because every user has different cookies, creating a unique cache key per user. For high cache hit ratios, keep the Vary header limited to headers that have a small number of distinct values.

What Are the SEO Implications of Temporary Redirects?

Temporary redirects have significant SEO implications that differ from 301 permanent redirects.

No link equity transfer — search engines do not transfer PageRank or other ranking signals through 302 or 307 redirects. The redirect target does not benefit from the authority of the original URL. This is intentional: a temporary redirect means the original URL will serve content again, so the original URL retains its ranking signals.

Original URL stays in index — search engines keep the original URL (not the redirect target) in their search results. This is the opposite of 301 behavior, where the search engine replaces the original URL with the destination URL.

Accidental 302 problem — one of the most common SEO mistakes is using 302 redirects for permanent URL changes. This prevents link equity transfer and keeps the old URL in search results, sometimes for months. Google may eventually recognize that a long-standing 302 should be treated as a 301, but this process is slow and unreliable. Always use 301 for permanent changes.

How Do You Implement Temporary Redirects?

In Nginx, use the return directive with the appropriate status code:

# 302 temporary redirect
location /promo {
    return 302 /summer-sale;
}

# 307 method-preserving temporary redirect
location /api/v1/submit {
    return 307 /api/v2/submit;
}

# 303 See Other (after POST processing)
# Typically done in application code, not Nginx

In Apache, use the Redirect directive or RewriteRule:

# 302 temporary redirect
Redirect 302 /promo /summer-sale

# 307 temporary redirect (preserves method)
Redirect 307 /api/v1/submit /api/v2/submit

# RewriteRule with 302
RewriteRule ^/old-promo$ /new-promo [R=302,L]

Remember that the default behavior of Apache's Redirect directive without a status code is 302, and the default for RewriteRule with the [R] flag is also 302. Always specify the status code explicitly to avoid confusion and ensure the intended behavior.