Clarify start/end query parameter and Range header edge cases - #113
Clarify start/end query parameter and Range header edge cases#113nsheff wants to merge 3 commits into
Conversation
- Allow start or end query parameters to be used independently - Change out-of-bounds start from 400 to 416 (matches EBI) - Add explicit 416 for out-of-bounds end - Align Range header behavior with RFC 7233 (clip last-byte-pos, reject first-byte-pos > length with 416) Fixes #107
andrewyatz
left a comment
There was a problem hiding this comment.
Agreed that codification of the spec is right here and I had not paid attention to RFC 7233 closely enough that one that exceeds length is clipped. Implementations will need to remember if they have been given a Range header vs args but that should be simple to code around.
I was worried that the reference Python implementation I wrote would fail this but on first read it looks to handle this.
|
IMHO because determining sequence length in advance requires the client to make an extra metadata request round trip, |
There's a case to be made that the originally specified 400 was more appropriate and the EBI implementation's behaviour is incorrect. The relevant RFCs describe 416 as being specifically for use when a Range header's set of ranges has been rejected. To use 416 in the absence of a Range header is contrary to that text — which may have been the reason for originally choosing 400. |
Co-authored-by: John Marshall <jmarshall@hey.com>
Co-authored-by: John Marshall <jmarshall@hey.com>
Summary
Addresses #107 by clarifying edge cases for
start/endquery parameters and Range headers.Changes:
startorendquery parameters to be used independentlystartfrom 400 Bad Request to 416 Range Not Satisfiable (matches EBI implementation)endlast-byte-posif it exceeds sequence lengthfirst-byte-posexceeds sequence lengthTesting
Tested against EBI implementation. See test script and issue comment for details.
Note: EBI has a bug where Range header with
first-byte-pos > lengthreturns 200 with full sequence instead of 416. This is not tested by the compliance suite.Fixes #107