- Software and digital services
- HTTP service
206
HTTP 206 Partial Content status: range request satisfied
Risk level
Low
Usually safe to check without specialist tools.
Urgency
Medium
Quick answer
HTTP 206 (Partial Content) is a 2xx success status showing the server fulfilled a GET range request with one or more parts of the representation. If a download stops early, check the response Content-Range and Content-Type headers to see whether the client must request the remaining bytes.
Safety first
Stop and check this first
- Do not configure uptime monitors or API gateways to alert on HTTP 206 as a failure, and never concatenate partial 206 bodies without verifying Content-Range byte offsets and the ETag validator.
Safe checks you can perform
- Verify whether the finished download or media stream reaches the complete length
- Compare the requested Range header with Content-Range, Content-Length, and Content-Type
- Check the HTTP method and If-Range or conditional headers on the request
Leave these tasks to a qualified professional
- Do not attempt this professional task: Audit origin server and CDN compliance for 206 required headers
- Do not attempt this professional task: Update client range handling to read Content-Range and request remaining bytes
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.
Audit origin server and CDN compliance for 206 required headers
What they doHave the backend developer or CDN administrator verify that 206 responses include Content-Range (or multipart/byteranges boundaries) along with Date, Cache-Control, ETag, Expires, Content-Location, and Vary whenever those headers would appear in a 200 OK response.
They must show youa curl -i capture from the origin and CDN showing Accept-Ranges, Content-Range, Content-Length, and ETag on a 206 response.
In writingthe origin or CDN configuration reviewed and the captured response headers.
Update client range handling to read Content-Range and request remaining bytes
What they doHave the application developer update the HTTP client to inspect Content-Type and Content-Range on every 206 response, verify ETag or Last-Modified consistency, and automatically issue follow-up GET requests with If-Range until all bytes are received.
They must show youa network log where a multi-part or subset 206 transfer is followed by a continuation GET request and produces the complete file.
In writingthe client version updated and the verified checksum of the reassembled representation.
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.
Verify whether the finished download or media stream reaches the complete length
- Who:
- You or your developer, in the browser or client application.
- How:
- Allow the download or media playback to finish and compare the final file size on disk against the total representation length advertised after the slash in Content-Range.
- Result that matters:
- Whether multiple 206 responses completed the transfer normally or left the file truncated.
- If the final assembled file matches the total length in Content-Range, that confirms the 206 responses were normal chunked range transfers and no error occurred.
- If the transfer stops with fewer bytes than the total length after the slash, that points to the client not requesting the remaining byte ranges or an interrupted connection.
- Evidence to keep:
- Record the final byte count on disk and the complete Content-Range header value from the response.
Evidence: RFC 9110 - HTTP Semantics · RFC 9110 section 15.3.7 - 206 Partial Content
Compare the requested Range header with Content-Range, Content-Length, and Content-Type
- Who:
- Your web developer, using browser network tools or curl -i.
- How:
- Inspect the client request Range header field and compare it with the 206 response Content-Type, Content-Range, Content-Length, and ETag headers.
- Result that matters:
- Whether the server transferred the entire requested range, a smaller subset, or a multipart/byteranges body.
- If Content-Range covers a smaller byte span than the Range header requested, that confirms the server sent a partial subset per RFC 9110 Section 15.3.7 and the client must issue another GET for the rest.
- If Content-Type is multipart/byteranges or Content-Range matches the requested span yet the client output is corrupt, that isolates the fault to the client's range reassembly logic.
- Evidence to keep:
- Save the exact request Range line and the response Content-Range, Content-Length, Content-Type, Date, and ETag headers.
Never treat Content-Length in a 206 response as the full file size; Content-Length only counts the octets in that partial message.
Evidence: RFC 9110 section 14 - Range Requests · RFC 9110 section 15.3.7 - 206 Partial Content
Check the HTTP method and If-Range or conditional headers on the request
- Who:
- Your developer, reviewing the client HTTP request configuration.
- How:
- Verify that the range request uses the GET method and inspect any If-Range, If-Match, or If-None-Match precondition headers attached to the request.
- Result that matters:
- RFC 9110 Section 14.2 defines range handling only for GET and evaluates Range only when a conditional GET would otherwise return 200 OK.
- If the client sends Range on POST, PUT, or another non-GET method, that explains why compliant servers ignore the Range header field.
- If GET is used with If-Range and the entity tag still matches the current representation, that confirms the server should return 206 with only the required headers.
- Evidence to keep:
- Keep a redacted trace of the request method, URI path, Range specifier, and validator headers.
Evidence: RFC 9110 section 14 - Range Requests · RFC 9110 section 15.3.7 - 206 Partial Content
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
- 206 Contenido parcial
- 206 Contenu partiel
- 206 Contenuto parziale
- 206 Partial Content
- 206 Teilinhalt
- código 206 Epson
- EcoTank 206 LINE and EXT port
- EcoTank 206 puertos LINE y EXT
- El cable telefónico no está bien conectado a los puertos LINE y EXT. del producto
- Epson 206
- Epson error code 206
- Epson ET-5800 206
- Epson ET-5805 206
- Epson L6550 206
- HTTP 206
- HTTP status 206
- The phone cable is incorrectly connected to the LINE and EXT. port of the product
What it means
IANA registers 206 Partial Content under RFC 9110 Section 15.3.7. It indicates that the server is successfully fulfilling a Range request on a GET method by transferring one or more subranges of the selected representation, described either by a single Content-Range header field or by a multipart/byteranges media type. Because RFC 9110 allows a server to send only a subset of the requested ranges for load balancing, cache efficiency, or temporary unavailability, status 206 alone never proves a server or network error; the client must inspect Content-Type and Content-Range and issue follow-up requests if needed.
Warnings and stop conditions
- Lowsource verified
Do not configure uptime monitors or API gateways to alert on HTTP 206 as a failure, and never concatenate partial 206 bodies without verifying Content-Range byte offsets and the ETag validator.
Evidence: IANA HTTP Status Code Registry · RFC 9110 section 15.3.7 - 206 Partial Content
Symptoms and causes
Probable causes · in order
- Successful fulfillment of a client GET request containing a Range headerConfirmed
The client sent a GET request with a satisfiable Range header (for example bytes) to resume a download or stream media chunks, and the server returned the requested bytes with status 206.
Evidence: IANA HTTP Status Code Registry · RFC 9110 section 14 - Range Requests · RFC 9110 section 15.3.7 - 206 Partial Content
- Server intentionally returning a smaller subset of the requested byte rangePossible
RFC 9110 Section 15.3.7 notes that a server might send only a subset of the data requested for reasons such as temporary unavailability, cache efficiency, or load balancing, expecting the client to request the remainder.
Evidence: RFC 9110 section 14 - Range Requests · RFC 9110 section 15.3.7 - 206 Partial Content
- Client failing to inspect Content-Range and Content-Type or chained rangesPossible
A 206 response is self-descriptive: Content-Length gives only the octets enclosed in this message while Content-Range gives the complete representation length, so a client that does not read Content-Range stops with an incomplete file.
Evidence: RFC 9110 section 15.3.7 - 206 Partial Content
Virtual technician
Does 206 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?