Accept-Ranges: advertising support for partial requests
Accept-Ranges tells clients that the server can serve part of this resource. The value bytes means range requests are supported, and none means they are not.
At a glance
- Direction
- Response only, and it is usually sent on the full 200 response.
- Defined in
- RFC 9110
- When absent
- Clients must assume range requests are unsupported, even if the server would actually honour one.
- Values
- bytes for byte ranges, none to state explicitly that ranges are not supported
- Where it belongs
- On the 200 or HEAD response, so a client knows before it asks
- Enables
- Resumable downloads, video seeking, and partial reads of large files
- Commonly missing on
- Dynamically generated or streamed responses
In detail
This is an advertisement, not a promise about a specific request. A client reads it from the first response, or from a HEAD, and decides whether resuming is possible before it starts. Video players in particular check it early, because seeking through a large file without range support means downloading everything up to the target position.
The value none is deliberately different from omitting the header. It says the server considered ranges and does not support them for this resource, which stops a client retrying with a Range header that will be ignored. Both are treated the same way by most clients, but the explicit form saves a wasted round trip.
Dynamically generated responses often lack the header for a good reason: a body assembled on the fly may not exist in a form that can be sliced, and honouring a range would mean regenerating everything up to the requested offset. Static file handlers and object stores support ranges naturally, which is why moving a large download behind an application server can quietly break resuming.
If your users download large files, this header failing to appear is worth treating as a bug. Without it a dropped connection at ninety percent means starting from zero, which on a slow or metered connection is the difference between a usable download and an impossible one.
Examples
HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Length: 146515
Accept-Ranges: bytescurl -sI https://example.com/files/archive.zip | grep -i accept-rangesNo output at all means resuming is probably unavailable, whatever the server would do with a Range header.
Things that catch people out
- Advertising bytes while a proxy in front strips or ignores Range headers gives clients a resume that silently restarts from the beginning.
- The header belongs on the full response. Sending it only on the 206 is too late, because the client had to guess in order to make that request.
- Compression on the fly and range support interact badly, since the byte offsets of a compressed stream do not match the ones the client recorded earlier.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Range: asking for part of a resource
How to request a byte range, what a suffix range does, why a server may ignore the header and return 200, and how to resume a download safely.
Content-Range: which bytes this partial response holds
How Content-Range describes a byte range, what the total size field means, the unsatisfied form sent with 416, and how multipart ranges are framed.
Content-Length: the size of the body in octets
What Content-Length counts, why it must never accompany Transfer-Encoding, what happens when it disagrees with the body, and when it may be omitted.
Content-Encoding: what compression was applied
What Content-Encoding declares, how it differs from Transfer-Encoding, why it changes the ETag, and how double compression happens in a proxy chain.
Transfer-Encoding: chunked framing on the connection
What chunked transfer encoding does, why it is a hop by hop property, why it must never accompany Content-Length, and why HTTP/2 forbids it entirely.
User-Agent: what the client says it is
Why User-Agent strings look the way they do, why browsers are freezing and reducing them, and what to use instead of parsing one for feature decisions.
Tools for this
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL