Subject: [Technical Errata Reported] RFC7233 (4358)

From: RFC Errata System <[email-masked]>
Date: Thu, 7 May 2015 11:43:32 -0700 (PDT)

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 <[email-masked]>

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.

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.

Alternative: maybe it should only be true if last-byte-pos is
absent.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7233 (draft-ietf-httpbis-p5-range-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 May 2015 21:39:06 +0200

Unless I'm missing something this sounds like a technical change to me.

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 May 2015 13:34:58 -0700

It sounds like a technical addition, not a technical change. Regardless, it
doesn't seem like an actual errata unless this topic came up during WG
discussion, was agreed to, but then it somehow didn't make it into the RFC.
Further, given that this is a "MAY", the second paragraph of the "Notes"
seems overblown, given that some browsers have figured out a way to do this
without breaking the spec.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 7 May 2015 17:22:11 -0700

> On May 7, 2015, at 11:43 AM, RFC Errata System <[email-masked]> wrote:
> 

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.

> 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

---

From: Tim <[email-masked]>
Date: Fri, 08 May 2015 01:30:24 +0000

Thanks Roy.

Apparently it was not clear to some that
"the protocol anticipates that the server might not send the same range[s] as requested"
which is why I though it might benefit rfc7233 to state the fact more directly/concisely.
I understand if you don't think rfc7233 need be more clear on that point.

---

From: Tim <[email-masked]>
Date: Thu, 07 May 2015 21:03:40 +0000

Actually "A response must include the full requested range." would break one of the intended reasons for the specification, resuming an interrupted download.
So really "A response may chose to satisfy only part of a requested range starting at the requested byte ." is implied and should be explicitly stated.

On Thu, May 7, 2015 at 3:47 PM, Tim <[email-masked] <mailto:[email-masked]>> wrote:
Hi Julian,

Thanks for the response.
Currently I think the RFC reads ambiguously as to whether this behavior is permitted.
I believe it should be permitted, but if not please explicitly state it should not be permitted in the RFC;
"A response must include the full requested range."

On Thu, May 7, 2015 at 3:39 PM, Julian Reschke <[email-masked] <mailto:[email-masked]>> wrote:
Unless I'm missing something this sounds like a technical change to me.

Best regards, Julian

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4358 <http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4358>

--------------------------------------
Type: Technical
Reported by: Tim <[email-masked] <mailto:[email-masked]>>

Section: 4

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Tim <[email-masked]>
Date: Thu, 07 May 2015 19:47:57 +0000

Hi Julian,

Thanks for the response.

Best regards, Julian

Section: 4

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------