HTTP 307 Temporary Redirect Status Code

What Does HTTP 307 Mean?

The HTTP 307 Temporary Redirect status code is defined in RFC 9110, Section 15.4.8. It indicates that the target resource resides temporarily under a different URI and the user agent must not change the request method when following the redirect.

This status code was introduced to resolve a long-standing ambiguity with HTTP 302. Although the HTTP/1.1 specification required 302 to preserve the request method, most browsers historically changed POST requests to GET when following a 302 redirect. HTTP 307 explicitly guarantees method preservation, making it the correct choice for redirecting POST, PUT, DELETE, and PATCH requests.

The server includes a Location header with the temporary URI. The client should continue using the original URI for future requests because the redirect is temporary and may change.

Common Causes of 307 Temporary Redirect

HSTS (HTTP Strict Transport Security): The most common cause. When a browser has an HSTS policy for a domain (via the Strict-Transport-Security header or HSTS preload list), it internally redirects any HTTP request to HTTPS using a 307. This happens entirely within the browser — no network request reaches the server.

Temporary API migrations: When an API endpoint is temporarily moved to a different server or path, 307 ensures POST/PUT/DELETE requests are forwarded with their body intact, unlike 302 which may drop the body.

Load balancing and failover: Load balancers may return 307 to redirect traffic to a backup server or a different region while preserving the original request method and payload.

A/B testing and canary deployments: Some traffic routing systems use 307 to send a subset of requests to a different backend version while maintaining the integrity of the original request.

HTTP 307 vs HTTP 302: Key Differences

For permanent method-preserving redirects, use 308 Permanent Redirect instead of 301.

How to Handle 307 Responses

For Developers

• Follow the Location header: Read the Location response header and resend the original request (same method and body) to the new URI
• Do not cache the redirect: Continue using the original URI for future requests unless the response explicitly includes caching headers
• Check for HSTS: If you see 307 redirects from HTTP to HTTPS in browser DevTools with (Internal Redirect), this is HSTS working correctly — not a server issue
• Handle redirect loops: Implement a maximum redirect count (most HTTP clients default to 20-30) to prevent infinite loops

For Server Administrators

• Use 307 intentionally: Only return 307 when the redirect is truly temporary and the method must be preserved
• Verify the Location URL: Ensure it points to a valid, reachable endpoint that accepts the same HTTP methods
• Consider 308 for permanent redirects: If the resource has moved permanently and the method must be preserved, use 308 instead
• Nginx example: return 307 https://$server_name$request_uri;
• Apache example: Redirect 307 /old-path https://example.com/new-path

HSTS and Internal 307 Redirects

The most common source of 307 redirects in modern browsers is HSTS (HTTP Strict Transport Security). When a site sends the header Strict-Transport-Security: max-age=31536000; includeSubDomains, the browser remembers that this domain should only be accessed over HTTPS.

For subsequent requests, if a user types http://example.com, the browser internally issues a 307 redirect to https://example.com before any network request is made. In Chrome DevTools, this appears as 307 Internal Redirect with a Non-Authoritative-Reason: HSTS header.

This internal redirect is a security feature and should not be "fixed." It protects against SSL stripping attacks by ensuring the browser never sends an unencrypted HTTP request to the domain.

Related Status Codes

🔍 Check Your IP Address

While you're here, find out your public IP address, location, and ISP details instantly.