Clarify 200 vs 206 status codes for Range header requests#114
Open
nsheff wants to merge 1 commit into
Open
Conversation
- Restructure Range header response options as clear bullet list - Clarify that 200 OK is for servers that don't support Range headers (not servers that "choose to ignore" valid requests) - Add explicit status code rules in Response section - Use SHOULD/MAY language per RFC 7233 for Range requests spanning entire sequence Fixes #106
andrewyatz
approved these changes
May 29, 2026
Collaborator
andrewyatz
left a comment
andrewyatz
left a comment
There was a problem hiding this comment.
Changes look good and matches what I had expected was the default behaviour of implementations. Assume that some will send back 200 for a partial request.
Can I check what we expect to happen if we request a subsequence that happens to be the entire length of the requested sequence. Spec as it reads would says 200 since the subsequence is the entire sequence
jmarshall
reviewed
May 29, 2026
Comment on lines
+201
to
+205
| When a request is successful: | ||
| - If the server returns the entire sequence and no Range header was specified, the server MUST return `200 OK` | ||
| - If a Range header was specified and the server returns only the requested sub-sequence, the server MUST return `206 Partial Content` | ||
| - If a Range header was specified but the server does not support Range headers, it MUST return `200 OK` with the entire sequence | ||
| - If a Range header requests the entire sequence (e.g., `Range: bytes=0-`), the server SHOULD return `206 Partial Content` to indicate Range header support, but MAY return `200 OK` |
Member
There was a problem hiding this comment.
That's much clearer, but it now appears to be just explaining how Range headers work. Is it necessary to spell this out in such detail in this specification, or should it just point to the relevant RFC section?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
200 OKis for servers that don't support Range headers (not servers that "choose to ignore" valid requests)Context
This PR addresses the inconsistencies identified in #106:
The key clarification: returning
200 OKwith the full sequence is only valid for servers that don't support Range headers — not servers that support them but arbitrarily ignore requests.Stacked on
This PR is stacked on #113 (
fix/sequence-params). Merge #113 first.Fixes #106