RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Source of RFC: httpbis (app)

Errata ID: 4391
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nathan Herring
Date Reported: 2015-06-11
Rejected by: Barry Leiba
Date Rejected: 2015-06-11

Section 2.1 says:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length, then the byte-range-set is satisfiable.
   Otherwise, the byte-range-set is unsatisfiable.

It should say:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length and the current length of the representation
   is non-zero, then the byte-range-set is satisfiable. Otherwise, the
   byte-range-set is unsatisfiable.

Notes:

Asking for a range that includes trailing bytes (e.g., Range: bytes=-1) when the entity is zero bytes is, as stated here, satisfiable, and yet the service would be forced to yield a 206 code and there is no valid representation of Content-Range header, since you cannot specify a range with no length using the byte range type, the none range type is specified in section 2.3 with a meaning for Accept-Ranges only, and there are no other acceptable ranges in the IANA registry.

The alternative would be that we could overload the use of the none range and return 206 with Content-Length: 0, Content-Range: none for these requests for final bytes.
--VERIFIER NOTES--
It also says, in the same section:

If the selected representation is shorter than the specified
suffix-length, the entire representation is used.

So the response for the posited request is 200 (not 206).

Report New Errata