ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

308

HTTP 308 Permanent Redirect status: method-preserving URI

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 308 Permanent Redirect means the target resource has a new permanent URI and any redirected request must keep its original HTTP method. Check the Location header field for the new permanent URI and update client callers to use that destination.

Safety first

Stop and check this first

  • Do not attempt to permanently replace target URIs automatically in an authoring client unless the connection is secured and the origin server is a trusted authority for the content being edited, as noted in RFC 9110 Section 15.4.9.

Safe checks you can perform

  • Inspect the 308 Location header field in a current web browser
  • Compare behavior between the failing client and a modern HTTP client
  • Check destination server logs for preserved method and cache headers

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Verify single-hop 308 rewrite rules and Cache-Control headers on the server
  • Do not attempt this professional task: Update client callers to the new permanent URI or upgrade legacy HTTP libraries

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.

  1. Verify single-hop 308 rewrite rules and Cache-Control headers on the server

    What they doHave the site or infrastructure administrator verify that the 308 rule points directly to the final canonical URI without redirect chains and set explicit Cache-Control directives.

    They must show youthe raw HTTP 308 response headers showing the single Location URI reference and the configured Cache-Control header.

    In writingthe server rewrite rule, the canonical target URI, and the deployment timestamp.

  2. Update client callers to the new permanent URI or upgrade legacy HTTP libraries

    What they doHave the application developer update hardcoded API endpoints and links to the new URI from the Location header field, and upgrade any legacy HTTP client library that fails to recognize status 308.

    They must show youa client log showing requests sent directly to the new permanent URI or following 308 with the original HTTP method preserved.

    In writingthe updated endpoint URI in the client configuration and the HTTP client library version verified.

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.

  1. Inspect the 308 Location header field in a current web browser

    No special tools

    Who:
    You or your developer can check the response in an up-to-date browser Network panel.
    How:
    Request the URI with DevTools Network open, click the 308 Permanent Redirect entry, and read the Location header field and subsequent request.
    Result that matters:
    Whether the Location header points directly to the new permanent URI and loads without extra hops.
    If the browser follows Location in one hop and the destination succeeds, that confirms a valid permanent redirect and indicates you should update your stored URI reference.
    If the browser aborts after multiple hops, that confirms a cyclical redirection chain in the server or proxy configuration.
    Evidence to keep:
    Record the original request URI, the Location header value, and the final status code.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.9 - 308 Permanent Redirect · RFC 9110 section 10.2.2 - Location

  2. Compare behavior between the failing client and a modern HTTP client

    No special tools

    Who:
    You or your developer can compare the failing application against a current browser or CLI tool.
    How:
    Send the same request from the failing application and from a current HTTP client, observing whether both follow the Location header field.
    Result that matters:
    Whether the failure happens only in a specific older client or across all clients.
    If a modern browser or HTTP client follows the 308 while the older application stops on status 308, that confirms the client does not recognize status 308 automatic redirection.
    If every client fails at the Location target URI, that rules out 308 client compatibility and isolates the problem to the destination endpoint.
    Evidence to keep:
    Save the client name, software version, and raw 308 response headers from the test.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.9 - 308 Permanent Redirect

  3. Check destination server logs for preserved method and cache headers

    Tools required

    Who:
    Your developer or platform administrator checks the origin server logs and response headers.
    How:
    Verify in the destination access log that redirected POST or PUT requests arrive with their original method, and inspect Cache-Control headers on the 308 response.
    Result that matters:
    Whether the redirected request reaches the new URI with the same HTTP method and whether stale 308 responses are being cached.
    If no redirected request reaches the destination log from a specific caller, that confirms the caller stopped at the 308 response or served a cached redirect elsewhere.
    If the request arrives at the new URI with its original method and payload, that rules out redirect transport issues and points to application logic on the new endpoint.
    Evidence to keep:
    Keep the matching access log lines from both the old and new URIs along with the 308 Cache-Control header.

    Never disable authentication checks on the new permanent URI to work around headers removed during cross-origin 308 redirects.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.9 - 308 Permanent 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

  • 308 Dauerhafte Weiterleitung
  • 308 Permanent Redirect
  • 308 Redirección permanente
  • 308 Redirection permanente
  • 308 Reindirizzamento permanente
  • événement Fronius 308
  • evento Fronius 308
  • Fronius Ereignis 308
  • Fronius event 308
  • Fronius inverter 308
  • Fronius Symo / Eco 308
  • Fronius Wechselrichter 308
  • HTTP 308
  • HTTP status 308
  • inversor Fronius 308
  • inverter Fronius 308
  • onduleur Fronius 308

What it means

RFC 9110 Section 15.4.9 defines HTTP 308 (Permanent Redirect) for resources assigned a new permanent URI where the user agent must not change the request method when following the Location header field. Like 301, a 308 response is heuristically cacheable unless explicit cache directives state otherwise, but like 307 it preserves unsafe methods such as POST across the redirect hop. RFC 9110 notes that 308 was introduced in June 2014 (RFC 7538) and may not be recognized by older HTTP clients, so the status code alone does not prove an origin server defect.

Warnings and stop conditions

  • Lowsource verified

    Do not attempt to permanently replace target URIs automatically in an authoring client unless the connection is secured and the origin server is a trusted authority for the content being edited, as noted in RFC 9110 Section 15.4.9.

    Evidence: RFC 9110 section 15.4.9 - 308 Permanent Redirect

Symptoms and causes

Probable causes · in order

  • Permanent endpoint move that requires preserving POST or other methodsCommon

    The server owner permanently moved a resource or API route and configured status 308 with a Location header field so clients follow the new permanent URI without converting POST requests to GET.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.9 - 308 Permanent Redirect

  • Legacy HTTP client or intermediate tool does not recognize status 308Possible

    As noted in RFC 9110 Section 15.4.9, status code 308 (June 2014) is much younger than its sibling 3xx codes and might not be recognized everywhere, causing older clients to treat it as an unhandled 3xx response.

    Evidence: IANA HTTP Status Code Registry · RFC 9110 section 15.4.9 - 308 Permanent Redirect

  • Heuristically cached 308 response or cyclical redirect chainPossible

    Because a 308 response is heuristically cacheable, an outdated Location header stored in a cache or a self-referencing rewrite rule can trap clients in a redirect loop.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 15.4.9 - 308 Permanent Redirect

Virtual technician

Does 308 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.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Sources: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsreviewed 2026-10-19 · verified

Was this entry useful?