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

416

HTTP 416 Range Not Satisfiable: byte range outside file

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 416 (Range Not Satisfiable) means none of the byte ranges in your Range request header overlap the current resource length, or the range set was rejected as excessive. Check the Content-Range */complete-length response header and retry the GET without Range.

Safety first

Stop and check this first

  • Never attempt to splice or recombine a rejected 416 response or an invalid Content-Range header with a locally cached file; RFC 9110 Section 14.4 mandates that recipients of an invalid Content-Range must not recombine the content with a stored representation.
  • Do not configure download clients to loop endlessly on HTTP 416 without stripping the invalid Range header, as repeated overlapping range requests can be flagged as a denial-of-service attack under RFC 9110 Section 15.5.17.

Safe checks you can perform

  • Compare the request Range header with the 416 Content-Range */complete-length value
  • Repeat the GET request once without the Range header field
  • Check whether the client sends If-Range when resuming cached downloads

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Configure origin and CDN 416 responses to include accurate Content-Range */complete-length
  • Do not attempt this professional task: Fix client range calculation, add If-Range validation, and handle 416 fallback

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. Configure origin and CDN 416 responses to include accurate Content-Range */complete-length

    What they doHave the backend or CDN administrator verify that the server calculates byte ranges against the encoded representation length and generates Content-Range: bytes */complete-length on every 416 response.

    They must show youa curl header output from the origin and CDN showing Content-Range: bytes */<complete-length> on a test range past the end of the file.

    In writingthe origin or CDN cache configuration applied for compressed and uncompressed representations.

  2. Fix client range calculation, add If-Range validation, and handle 416 fallback

    What they doHave the application developer ensure byte int-range requests use zero-based offsets where first-pos <= last-pos and first-pos < complete-length, coalesce overlapping ranges in ascending order, attach If-Range with the cached ETag, and fall back to a full GET when 416 is received.

    They must show youa test capture where a valid byte range returns 206 Partial Content and an out-of-bounds offset cleanly falls back to a full 200 OK download.

    In writingthe updated client range-request logic, the If-Range validator policy, and the release version containing the fix.

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. Compare the request Range header with the 416 Content-Range */complete-length value

    Tools required

    Who:
    Your developer or site administrator inspecting the failed GET exchange.
    How:
    Read the client's Range request header (for example Range: bytes=50000-) and compare it with the Content-Range header field in the 416 response (for example Content-Range: bytes */47022).
    Result that matters:
    RFC 9110 Section 14.4 and Section 15.5.17 state that the unsatisfied-range value */complete-length in a 416 response specifies the current length of the selected representation.
    If every requested int-range has a first-pos greater than or equal to the complete-length reported in Content-Range, that confirms the client requested byte offsets past the end of the current representation.
    If first-pos is less than complete-length yet 416 is returned, that points to an invalid last-pos (< first-pos), an unsupported range-unit, or server rejection of overlapping or excessive subranges.
    Evidence to keep:
    Record the exact Range request header, the 416 Content-Range response header, and the target URI.

    Never attempt to recombine partial content with a cached file when Content-Range is invalid or returns 416; RFC 9110 Section 14.4 forbids recombining invalid ranges.

    Evidence: RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

  2. Repeat the GET request once without the Range header field

    Tools required

    Who:
    You or your developer using curl or a browser session.
    How:
    Send a single ordinary GET or HEAD request to the same URI without any Range header and inspect the 200 (OK) status, Content-Length, ETag, and Accept-Ranges headers.
    Result that matters:
    You verify whether the full representation is available and learn its current octet length and validator.
    If the un-ranged GET returns 200 OK with a smaller Content-Length (or 0 bytes) than the client's resume offset, that confirms the local partial download state was out of sync with the resource size.
    If the response includes Accept-Ranges:
    none, that indicates the upstream server advises clients not to attempt range requests on that request path.
    Evidence to keep:
    Save the 200 OK response headers showing Content-Length, ETag, and Accept-Ranges.

    Use a single read-only HEAD or GET request so you do not flood the origin server with repeated range retries.

    Evidence: RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

  3. Check whether the client sends If-Range when resuming cached downloads

    No special tools

    Who:
    Your client or media-player developer reviewing resume logic.
    How:
    Check whether the downloader sends If-Range with the stored ETag or Last-Modified validator alongside the Range header, and whether it coalesces multiple small ranges into ascending order.
    Result that matters:
    RFC 9110 Section 14.2 and Section 13.1.5 explain that If-Range lets the server return the full 200 representation automatically when the validator no longer matches, instead of failing when offsets shift.
    If the client sends raw byte offsets from an old cached file without If-Range, that isolates the 416 error to unvalidated resume offsets in the client.
    If the client sends dozens of small or overlapping byte ranges in a single header, that points to the anti-DoS range limit described in RFC 9110 Section 14.2 and Section 15.5.17.
    Evidence to keep:
    Keep a log of the client's Range and If-Range header construction logic.

    Evidence: RFC 9110 - HTTP Semantics · RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

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

  • 416 Bereich nicht erfüllbar
  • 416 Intervallo non soddisfacibile
  • 416 Plage non satisfaisable
  • 416 Range Not Satisfiable
  • 416 Rango no satisfacible
  • événement Fronius 416
  • evento Fronius 416
  • Fronius Ereignis 416
  • Fronius event 416
  • Fronius inverter 416
  • Fronius Symo / Eco 416
  • Fronius Wechselrichter 416
  • HTTP 416
  • HTTP status 416
  • inversor Fronius 416
  • inverter Fronius 416
  • onduleur Fronius 416

What it means

Defined in RFC 9110 Section 15.5.17 and Section 14, and registered by IANA under 4xx Client Error, HTTP 416 (Range Not Satisfiable) indicates the server rejected the Range header field on a GET request because none of the requested ranges are satisfiable or the client requested an excessive number of small or overlapping ranges. For bytes, an int-range is satisfiable only when its first-pos is less than the current length of the selected representation, and the 416 response should include Content-Range: bytes */complete-length. By itself, 416 does not prove the server is broken.

Warnings and stop conditions

  • Mediumsource verified

    Never attempt to splice or recombine a rejected 416 response or an invalid Content-Range header with a locally cached file; RFC 9110 Section 14.4 mandates that recipients of an invalid Content-Range must not recombine the content with a stored representation.

    Evidence: RFC 9110 section 14 - Range Requests

  • Lowsource verified

    Do not configure download clients to loop endlessly on HTTP 416 without stripping the invalid Range header, as repeated overlapping range requests can be flagged as a denial-of-service attack under RFC 9110 Section 15.5.17.

    Evidence: RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

Symptoms and causes

Probable causes · in order

  • Requested byte first-pos is greater than or equal to the current representation lengthConfirmed

    Under RFC 9110 Section 14.1.2, a bytes int-range (first-pos-last-pos) in a GET request is satisfiable only if first-pos is strictly less than the current length of the selected representation; offsets at or beyond the file size trigger 416.

    Evidence: IANA Hypertext Transfer Protocol Status Code Registry · RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

  • Zero-length representation requested with a byte int-range or zero suffix-lengthCommon

    RFC 9110 Section 14.1.2 states that when a selected representation has zero length, the only satisfiable form of range-spec in a GET request is a suffix-range with a non-zero suffix-length.

    Evidence: RFC 9110 section 14 - Range Requests

  • Malformed range syntax or excessive small or out-of-order overlapping rangesPossible

    RFC 9110 Section 14.1.1 and Section 14.2 allow a server to reject a Range field with 416 when last-pos is less than first-pos, when more than two overlapping ranges are sent, or when many small ranges are requested (a potential denial-of-service pattern).

    Evidence: RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

  • Resume downloader using a stale file offset after the upstream asset was truncated or replacedPossible

    When a client resumes a partial download without an If-Range validator (Section 13.1.5) and the representation on the origin or CDN has shrunk, the stored byte offset can exceed the new complete-length.

    Evidence: RFC 9110 - HTTP Semantics · RFC 9110 section 15.5.17 - 416 Range Not Satisfiable · RFC 9110 section 14 - Range Requests

Virtual technician

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