What's the difference between a 302 and a 307 redirect?

HTTP 302 vs. 307 Redirects: Understanding the Nuances

Explore the critical differences between HTTP 302 Found and 307 Temporary Redirect status codes, their implications for user agents and SEO, and when to use each for effective web development.

HTTP redirects are essential for managing web content, handling URL changes, and guiding users and search engines to the correct resources. Among the various redirect types, 302 Found and 307 Temporary Redirect are often confused due to their similar 'temporary' nature. However, a crucial distinction lies in how they instruct the user agent (e.g., web browser) to handle the HTTP method of the subsequent request. Understanding this difference is vital for maintaining web application integrity, preventing unexpected behavior, and ensuring proper SEO.

HTTP 302 Found: The Original Temporary Redirect

The HTTP 302 Found status code indicates that the requested resource has been temporarily moved to a different URI. Historically, user agents would often change the request method from POST to GET for the subsequent request, even though the specification didn't explicitly require it. This behavior became a de facto standard, leading to potential issues where a POST request intended for one endpoint would be re-sent as a GET to another, losing the original request body. While modern browsers are more compliant with the RFCs, the legacy behavior of changing POST to GET is still a common expectation when encountering a 302 redirect, especially in older systems or less strict implementations.

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: POST /old-resource
    Server-->>Client: HTTP/1.1 302 Found\nLocation: /new-resource
    Note right of Server: Server indicates temporary move
    Client->>Server: GET /new-resource
    Note left of Client: Client changes POST to GET
    Server-->>Client: HTTP/1.1 200 OK\n(Content of /new-resource)

Sequence diagram illustrating a 302 redirect changing a POST request to GET.

HTTP 307 Temporary Redirect: Method Preservation

The HTTP 307 Temporary Redirect status code was introduced to address the ambiguity of the 302 redirect regarding method preservation. When a server responds with a 307, it explicitly instructs the user agent to repeat the request to the new URI using the exact same HTTP method as the original request. This means if the initial request was a POST, the subsequent request to the new location will also be a POST, preserving the request body and headers. This behavior makes 307 redirects safer and more predictable for scenarios where the request method and body are crucial, such as form submissions or API calls.

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: POST /old-api-endpoint\nBody: { "data": "value" }
    Server-->>Client: HTTP/1.1 307 Temporary Redirect\nLocation: /new-api-endpoint
    Note right of Server: Server indicates temporary move, preserve method
    Client->>Server: POST /new-api-endpoint\nBody: { "data": "value" }
    Note left of Client: Client preserves POST method and body
    Server-->>Client: HTTP/1.1 200 OK\n(Response from /new-api-endpoint)

Sequence diagram illustrating a 307 redirect preserving a POST request method and body.

Key Differences and Use Cases

The fundamental difference between 302 and 307 lies in their handling of the request method. While both indicate a temporary redirection, 307 guarantees method preservation, making it the more robust choice for certain scenarios. Search engines generally treat both 302 and 307 as temporary, meaning they typically do not transfer 'link juice' or update their index with the new URL as they would with a 301 permanent redirect. However, consistent use of the correct redirect type is crucial for user experience and application logic.

Comparison of 302 Found vs. 307 Temporary Redirect

Here's a summary of when to use each:

1. When to use 302 Found

Use 302 when the redirect is truly temporary, and you don't mind if a POST request is converted to a GET. This might be acceptable for simple redirects where no sensitive data is in the request body, or for older applications where the client behavior is known to convert POST to GET.

2. When to use 307 Temporary Redirect

Use 307 when the redirect is temporary, and it is absolutely critical to preserve the original HTTP method (e.g., POST, PUT, DELETE) and the request body. This is the preferred choice for API endpoints, form submissions, or any scenario where data integrity across the redirect is paramount.

Implementation Examples

Implementing these redirects varies depending on your server environment or programming language. Here are a few common examples.

PHP

Node.js (Express)

const express = require('express'); const app = express();

app.get('/old-resource-302', (req, res) => { res.redirect(302, '/new-resource-302'); });

app.post('/old-resource-307', (req, res) => { res.redirect(307, '/new-resource-307'); });

app.listen(3000, () => console.log('Server running on port 3000'));

Apache (.htaccess)

302 Redirect

RedirectMatch 302 ^/old-resource-302$ /new-resource-302

307 Redirect (requires mod_rewrite)

RewriteEngine On RewriteRule ^old-resource-307$ /new-resource-307 [R=307,L]

Nginx

server { listen 80; server_name example.com;

location /old-resource-302 {
    return 302 /new-resource-302;
}

location /old-resource-307 {
    return 307 /new-resource-307;
}

}