- Software and digital services
- HTTP service
307
HTTP 307 Temporary Redirect status: method-preserving hop
Risk level
Low
Usually safe to check without specialist tools.
Urgency
Medium
Quick answer
HTTP 307 Temporary Redirect means the resource resides temporarily at a different URI and the client must repeat its request without changing the HTTP method. Check the Location header for the temporary URI and keep using the original URI for future requests.
Safety first
Stop and check this first
- Do not attempt to replace bookmarks or hardcoded client endpoints with a 307 Location URI; RFC 9110 Section 15.4.8 specifies that the redirection can change over time and clients ought to continue using the original target URI.
Safe checks you can perform
- Check the temporary Location URI reference in the 307 response
- Compare the HTTP method and request headers before and after the 307 hop
- Check whether the client library blocks automatic 307 redirects on unsafe methods
Leave these tasks to a qualified professional
- Do not attempt this professional task: Verify temporary gateway routing and method handling at the destination URI
- Do not attempt this professional task: Keep authenticated 307 redirects on the same origin or re-authenticate safely
What a technician must be able to justify
Technician visit
These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.
These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.
Verify temporary gateway routing and method handling at the destination URI
What they doHave the site or API administrator verify that the temporary Location target accepts the original HTTP method and payload, and remove the 307 rule once the temporary condition ends.
They must show youa live request trace showing the 307 Location header and the temporary endpoint accepting the preserved HTTP method.
In writingthe reason for the temporary 307 rule, the target Location URI, and the scheduled removal condition.
Keep authenticated 307 redirects on the same origin or re-authenticate safely
What they doHave the developer keep temporary API redirects within the same trusted origin or implement an explicit token handoff when a 307 redirect crosses origins.
They must show youa redacted trace of the redirected request succeeding at the temporary URI without exposing credentials to untrusted hosts.
In writingthe origin boundary policy and the exact headers retained or reissued across the 307 redirect.
Before accepting a part or repair
Nothing has been shown yet. Do not accept a part swap based on the code alone.
Follow these steps
Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.
Check the temporary Location URI reference in the 307 response
- Who:
- You or your developer can inspect the 307 response in the browser Network tab.
- How:
- Select the 307 Temporary Redirect entry, read the Location header field, and verify whether the temporary destination URI completes the request.
- Result that matters:
- Whether the Location header resolves to a reachable temporary endpoint without entering a redirection loop.
- If the temporary URI completes normally, that confirms an intentional temporary redirect and means future requests should still target the original URI.
- If the Location header points back into a cycle of 3xx responses, that confirms a cyclical redirection misconfiguration on the server or gateway.
- Evidence to keep:
- Keep the original target URI, the temporary Location header value, and the timestamp of the trace.
Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.8 - 307 Temporary Redirect · RFC 9110 section 10.2.2 - Location
Compare the HTTP method and request headers before and after the 307 hop
- Who:
- Your application developer inspects the client trace or server access logs.
- How:
- Check that the redirected request sent to the Location URI kept the exact HTTP method (for example POST) and see whether Authorization or Cookie headers were removed across origins.
- Result that matters:
- Whether the method was preserved and whether authentication headers were stripped on the second request.
- If the Location URI is on a different origin and the second request lacks Authorization or Cookie headers, that confirms standard RFC 9110 header stripping caused the downstream authentication prompt or 401.
- If a non-compliant client rewrote POST to GET on a 307 response, that isolates the fault to the client HTTP library violating Section 15.4.8.
- Evidence to keep:
- Save the redacted request headers and method lines from both the initial and redirected requests.
Never configure an HTTP client to blindly forward Authorization tokens or session cookies to arbitrary third-party origins across redirects.
Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.8 - 307 Temporary Redirect
Check whether the client library blocks automatic 307 redirects on unsafe methods
- Who:
- Your developer reviews the HTTP client configuration and redirect policy.
- How:
- Inspect the client redirect settings for POST, PUT, or DELETE requests when receiving HTTP 307.
- Result that matters:
- Whether the client library stops on 307 for non-safe methods instead of resending the payload automatically.
- If GET requests follow the 307 while POST or PUT requests stop on 307, that confirms the client enforces the RFC 9110 Section 15.4 safety restriction on automatic redirection of unsafe methods.
- If both GET and POST fail to reach the Location host, that rules out method-specific redirect blocking and points to DNS, routing, or gateway rules on the temporary URI.
- Evidence to keep:
- Record the HTTP client library version, redirect policy flags, and test output.
Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.8 - 307 Temporary Redirect
Still not solved
If the error persists, stop here. See what the technician must do and show you.
Where this code applies
A code is meaningful only inside the right product and version context.
Primary scope
- System
- Software and digital services
- Brand
- HTTP
- Product type
- HTTP service
Known code variants
- 307 Redirección temporal
- 307 Redirection temporaire
- 307 Reindirizzamento temporaneo
- 307 Temporäre Weiterleitung
- 307 Temporary Redirect
- événement Fronius 307
- evento Fronius 307
- Fronius Ereignis 307
- Fronius event 307
- Fronius inverter 307
- Fronius Symo / Eco 307
- Fronius Wechselrichter 307
- HTTP 307
- HTTP status 307
- inversor Fronius 307
- inverter Fronius 307
- onduleur Fronius 307
What it means
Under RFC 9110 Section 15.4.8, HTTP 307 (Temporary Redirect) informs the client that the target resource is temporarily reachable at the URI reference given in the Location header field, while prohibiting any automatic user agent redirect from altering the original request method. Unlike status 302, an automatic 307 redirect must resend a POST request as POST, though Section 15.4 requires clients to strip resource-specific headers such as Authorization, Cookie, Origin, and Referer when redirecting across origins. Status 307 alone does not prove a server error, as it is a standard protocol redirect.
Warnings and stop conditions
- Lowsource verified
Do not attempt to replace bookmarks or hardcoded client endpoints with a 307 Location URI; RFC 9110 Section 15.4.8 specifies that the redirection can change over time and clients ought to continue using the original target URI.
Evidence: RFC 9110 section 15.4.8 - 307 Temporary Redirect
Symptoms and causes
Probable causes · in order
- Temporary URI routing where the request method must remain unchangedCommon
The server temporarily directs requests to a different URI via the Location header field and uses status 307 so user agents do not rewrite unsafe methods such as POST into GET.
Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.8 - 307 Temporary Redirect
- Authorization or Cookie headers removed during a cross-origin 307 hopPossible
When following a redirect automatically, RFC 9110 Section 15.4 instructs the user agent to remove resource-specific headers including Authorization and Cookie where security implications exist, causing the temporary destination to reject the unauthenticated request.
Evidence: RFC 9110 section 15.4 - Redirection 3xx
- Unsafe method redirect blocked or awaiting user confirmationPossible
RFC 9110 Section 15.4 notes that automatic redirection requires care for methods not known to be safe (such as POST, PUT, or DELETE), so strict HTTP clients may decline to follow a 307 automatically without caller approval.
Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.8 - 307 Temporary Redirect
Virtual technician
Does 307 still appear after these checks?
Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.
Sources and technical references
- 1
IANA HTTP Status Code Registry
Internet Assigned Numbers Authority · 2025 · standard
- 2
IETF / RFC Editor · 2022 · standard
Was this entry useful?