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

300

HTTP 300 Multiple Choices response: several resource URIs

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 300 Multiple Choices means the requested target has more than one representation, each with its own URI. Check the response body for a list of alternative links or inspect the Location header field for the server's preferred URI reference.

Safety first

Stop and check this first

  • Never forward Authorization or Cookie headers to an unfamiliar origin when following a 300 Location link; RFC 9110 Section 15.4 notes that resource-specific headers carry security implications across redirects.

Safe checks you can perform

  • Inspect the 300 response payload for listed alternative URIs
  • Check whether the 300 response includes a Location header field
  • Verify how your API or HTTP client handles status 300 and caching

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Publish a preferred Location header and representation list on the server
  • Do not attempt this professional task: Update the HTTP client to request the specific representation URI or follow Location

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. Publish a preferred Location header and representation list on the server

    What they doHave the site or API administrator configure the origin server so non-HEAD 300 responses include a clear list of representation metadata and URI references, plus a single Location header field when a preferred representation exists.

    They must show youa raw HTTP 300 response capture displaying the single Location header field and the payload list of representation URIs.

    In writingthe canonical URI table for each representation, the preferred Location rule, and the explicit Cache-Control header policy.

  2. Update the HTTP client to request the specific representation URI or follow Location

    What they doHave the application developer configure the client to call the specific representation URI directly, follow the server's Location header reference, or parse the agreed media type returned in the 300 body.

    They must show youa client trace completing the request against the selected representation URI without stopping on status 300.

    In writingthe exact URI reference or content negotiation rule configured in the client code.

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 300 response payload for listed alternative URIs

    No special tools

    Who:
    You or your developer can check the response in a browser or HTTP inspection tool.
    How:
    Open the non-HEAD 300 response body and look for the hypertext or structured list of representation metadata and URI references.
    Result that matters:
    Whether the response body provides specific URI identifiers and whether selecting one loads the expected representation.
    If the payload lists alternative URIs and your chosen URI loads normally, that confirms reactive negotiation is working as designed on the server.
    If the response to a GET request has an empty body and no usable links, that points to an incomplete 300 response configuration on the origin server.
    Evidence to keep:
    Save a copy of the 300 response body, the Content-Type header value, and the request timestamp.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices

  2. Check whether the 300 response includes a Location header field

    No special tools

    Who:
    You or your developer can inspect the response headers in the browser Network panel.
    How:
    Select the HTTP 300 exchange in the Network tab and read the response headers for a single Location URI reference.
    Result that matters:
    Whether the server advertised a preferred representation in Location and whether that URI reference resolves cleanly against the target URI.
    If a single valid Location header field is present and resolves to a working representation, that confirms the server offers a preferred choice for automatic redirection.
    If Location is absent or multiple Location lines were combined into an invalid reference, that rules out simple automatic redirection and isolates the issue to missing preference metadata or malformed header generation.
    Evidence to keep:
    Record the exact Location header value, the original target URI, and the response Date header.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices · RFC 9110 section 10.2.2 - Location

  3. Verify how your API or HTTP client handles status 300 and caching

    Tools required

    Who:
    Your application developer performs this check in the client runtime configuration.
    How:
    Test the client against the 300 endpoint to see if it follows the Location header field or parses the alternative list, and check Cache-Control headers since 300 is heuristically cacheable.
    Result that matters:
    Whether the client stops on 300, follows Location, or serves a heuristically cached 300 response.
    If a web browser displays or follows the choice while the custom client fails on the same URI, that isolates the problem to client-side 300 handling rather than server availability.
    If an outdated 300 response persists after server changes, that indicates a heuristically cached 300 entry in a browser or intermediate cache.
    Evidence to keep:
    Keep the client request log, HTTP library redirect settings, and response cache headers.

    Never disable TLS certificate validation or send live Authorization credentials to untrusted alternative URIs while testing client redirect behavior.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices · RFC 9110 section 15.4 - Redirection 3xx

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

  • 300 Choix multiples
  • 300 Mehrere Auswahlmöglichkeiten
  • 300 Multiple Choices
  • 300 Múltiples opciones
  • 300 Scelte multiple
  • Growatt 300 tensión de red fuera de rango
  • Growatt AC V Outrange
  • Growatt error 300
  • Growatt Error: 300
  • Growatt grid voltage out of range
  • HTTP 300
  • HTTP status 300

What it means

In RFC 9110 Section 15.4.1, HTTP status 300 (Multiple Choices) indicates that the origin server offers multiple representations for the target resource, each identified by its own specific URI, and asks the user or client to engage in reactive negotiation (Section 12). When the server has a preferred representation, it should send that URI reference in the Location header field, and for methods other than HEAD it should return a payload listing the available alternatives. Because the HTTP standard does not mandate a single format for automatic selection, a 300 status alone does not prove a server malfunction or broken endpoint.

Warnings and stop conditions

  • Lowsource verified

    Never forward Authorization or Cookie headers to an unfamiliar origin when following a 300 Location link; RFC 9110 Section 15.4 notes that resource-specific headers carry security implications across redirects.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices · RFC 9110 section 15.4 - Redirection 3xx

Symptoms and causes

Probable causes · in order

  • Reactive content negotiation offered for multiple representationsCommon

    The origin server hosts more than one representation of the requested resource, each with its own specific URI identifier, and returns status 300 so the user or user agent can choose the representation that matches its needs.

    Evidence: IANA HTTP Status Code Registry · RFC 9110 section 15.4.1 - 300 Multiple Choices

  • No Location header field sent for automatic client redirectionPossible

    RFC 9110 states that a server with a preferred choice should generate a Location header field, so when the server has no preferred representation and omits Location, the client cannot redirect automatically via that header.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices · RFC 9110 section 10.2.2 - Location

  • Automated HTTP client unable to parse the 300 alternative listPossible

    Because RFC 9110 does not define a specific format for automatic selection from a 300 response payload, an API client that does not understand the returned media type stops on status 300 instead of picking an alternative URI.

    Evidence: RFC 9110 section 15.4.1 - 300 Multiple Choices · RFC 9110 section 15.4 - Redirection 3xx

Virtual technician

Does 300 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?