Re: [Technical Errata Reported] RFC7233 (4358)

> On May 7, 2015, at 11:43 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7233,
> "Hypertext Transfer Protocol (HTTP/1.1): Range Requests".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4358
> 
> --------------------------------------
> Type: Technical
> Reported by: Tim <elatllat@gmail.com>
> 
> Section: 4
> 
> Original Text
> -------------
> The 206 (Partial Content) status code indicates that the server is
> successfully fulfilling a range request for the target resource by
> transferring one or more parts of the selected representation that
> correspond to the satisfiable ranges found in the request's Range
> header field (Section 3.1).
> 
> Corrected Text
> --------------
> The 206 (Partial Content) status code indicates that the server is
> successfully fulfilling a range request for the target resource by
> transferring one or more parts of the selected representation that
> correspond to the satisfiable ranges found in the request's Range
> header field (Section 3.1). A response may chose to satisfy only
> part of a requested range.

This is not an errata.  The 206 indicates that it is transferring
"one or more parts".  That does not imply all.  It goes on to describe
coalescing of many small or overlapping ranges, which is clearly not
the same as sending the same ranges as found in the Ranges header field.

Furthermore, the normative requirement is in 3.1:

   If all of the preconditions are true, the server supports the Range
   header field for the target resource, and the specified range(s) are
   valid and satisfiable (as defined in Section 2.1), the server SHOULD
   send a 206 (Partial Content) response with a payload containing one
   or more partial representations that correspond to the satisfiable
   ranges requested, as defined in Section 4.

Note that the satisfiable ranges are not necessarily the same as the
ranges specified in the Range header field.  They might also be reduced or
coalesced for a 206 response, and there might be other reasons for the
server's SHOULD to be avoided.

Regardless, the protocol anticipates that the server might not send the
same ranges as requested, which is why it doesn't need to be a MUST for interop.
The content received in a 206 response is self-descriptive.
It does not even reference the Ranges field-values used in the request.

> Notes
> -----
> Firefox and Chrome already behave as if the "Corrected Text"
> statement is true.
> 
> It may be desirable if for example a user returns to a
> html5 video with auto play, pauses the video and is only
> interested in responding to a comment on the page. In this example
> it would be unnecessarily costly to transfer the whole 128GB when
> the user only consumes a few MB.

Pausing a video doesn't have anything to do with Range requests.
Perhaps the next request, after a resume action, but not the pause itself.

....Roy

Received on Friday, 8 May 2015 00:22:37 UTC