Subject: APPSDIR review of draft-ietf-httpbis-p5-range-24

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Oct 2013 01:13:08 -0700

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on APPSDIR, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-httpbis-p5-range-24
Title: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Reviewer: S. Moonesamy
Review Date: October 29, 2013
IETF Last Call Date: October 21, 2013

Summary: This draft requires further review.

This document defines HTTP/1.1 range requests, partial responses, and 
the multipart/byteranges media type.

This document is well-written.  The Introduction section mentions 
that the byte range feature is an optional feature of HTTP.  This 
feature can be used to, for example, resume the download of a large 
file.  The feature is part of the set of documents for the protocol 
while the feature can be considered as not being part of the base 
protocol.  The Security Consideration sections (see Part 1 and Part 
2) do not discuss about whether the feature can be misused (e.g. 
denial of service).

Major Issues:

In Section 2.3:

   'The "Accept-Ranges" header field allows a server to indicate that it
    supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send 
"Accept-Ranges: bytes"; it's a RFC 2119 "may".  It seems better if 
there is a recommendation for the server to advertise the feature if 
the server supports it.  There is the following text in Section 3.1:

   "A server MAY ignore the Range header field.  However, origin servers
    and intermediate caches ought to support byte ranges when possible,
    since Range supports efficient recovery from partially failed
    transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range 
header field but it is politely recommended that origin servers and 
intermediate caches support it.  This looks like a workaround to 
avoid introducing a RFC 2119 "should".  The text explains why it is 
worthwhile to support byte ranges while the Introduction sections 
states that this feature is optional.

In Section 3.2:

"HTTP-date" is defined in the Appendix C.  I suggest importing the 
rules should be in Section 1.2.

In Section 2.1:

    "Other valid (but not canonical) specifications of the second 500
     bytes (byte offsets 500-999, inclusive):

         bytes=500-600,601-999
         bytes=500-700,601-999"

And Section 3.1:

   "A client that is requesting multiple ranges SHOULD list those ranges
    in ascending order (the order in which they would typically be
    received in a complete representation) unless there is a specific
    need to request a later part earlier."

I am trying to understand what the server should do when it receives 
one or several overlapping ranges.

In Section 4.1:

  "If multiple parts are being transferred, the server generating the
   206 response MUST generate a "multipart/byteranges" payload, as
   defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

   "If the selected representation would have had a Content-Type
    header field in a 200 (OK) response, the server SHOULD generate
    that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the 
above.  When can the "should" be ignored?  Is the server supposed to 
generate the same Content-Type header field in each header area if 
the selected representation would have a Content-Type header field 
for a 200 (OK) response?

   "When a multipart response payload is generated, the server SHOULD
    send the parts in the same order that the corresponding byte-range-
    spec appeared in the received Range header field, excluding those
    ranges that were deemed unsatisfiable or that were coalesced into
    other ranges."

It is recommended in the Section 3.1 that the client lists the ranges 
it requests in ascending order.  The above text recommends that the 
server should send the parts in the same order as the request.  There 
can be an interoperability issue when the two sides are told to do 
RFC 2119 "should".

In Appendix A:

   "The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

   "Range requests are an OPTIONAL feature of HTTP, designed so that
    recipients not implementing this feature (or not supporting it
    for the target resource) can respond as if it is a normal GET
    request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to 
RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

   "In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
    length are expressed as decimal number of octets.  Since there is no
    predefined limit to the length of a payload, recipients ought to
    anticipate potentially large decimal numerals and prevent parsing
    errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of 
draft-ietf-httpbis-p1-messaging-24 about integer conversion and a 
reference to Section 9.3 of that draft.  I may have missed integer 
conversation issues in the reviews.  I suggest doing a verification 
to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

   "Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

   "The only range unit defined by HTTP/1.1 is "bytes".  HTTP/1.1
    implementations MAY ignore ranges specified using other units.
    HTTP/1.1 has been designed to allow implementations of applications
    that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything 
to add one more registry".  The text from RFC 2616 suggests that the 
only unit specified is "bytes" and that HTTP/1.1 does not depend upon 
the knowledge of this optional feature.  I don't see any reason to 
have other range units.

In Section 2.3:

   "A server that does not support any kind of range request for the
    target resource resource MAY send"

The word "resource" is duplicated.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2013 16:03:14 +0100

On 2013-10-29 09:13, S Moonesamy wrote:
> ...
> I consider the creation of the registry as "it does not cost anything to
> add one more registry".  The text from RFC 2616 suggests that the only
> unit specified is "bytes" and that HTTP/1.1 does not depend upon the
> knowledge of this optional feature.  I don't see any reason to have
> other range units.
> ...

Actually, it was a case of "this is used in the wild already, and more 
use is coming up, so better document it properly and add the registry". 
See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/85> for the history.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2013 16:27:36 +0100

Hi SM,

thanks a lot for the incoming reviews! I'm tracking them in the WG's 
trac instance.

Below are comments on the non-editorial parts of your review.

On 2013-10-29 09:13, S Moonesamy wrote:
> "Accept-Ranges: bytes"; it's a RFC 2119 "may".  It seems better if there
> is a recommendation for the server to advertise the feature if the
> server supports it.  There is the following text in Section 3.1:

Well, it's optional, and we didn't want to make it a SHOULD. It adds 
overhead to GET responses, even though only few clients will make range 
requests.

> intermediate caches support it.  This looks like a workaround to avoid
> introducing a RFC 2119 "should".  The text explains why it is worthwhile
> to support byte ranges while the Introduction sections states that this
> feature is optional.

Yes. Do you think this is a problem? Why?

> In Section 3.2:
>
> "HTTP-date" is defined in the Appendix C.  I suggest importing the rules
> should be in Section 1.2.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/505>

> I am trying to understand what the server should do when it receives one
> or several overlapping ranges.

"A server that supports range requests MAY ignore or reject a Range 
header field that consists of more than two overlapping ranges, or a set 
of many small ranges that are not listed in ascending order, since both 
are indications of either a broken client or a deliberate denial of 
service attack (Section 6.1). A client SHOULD NOT request multiple 
ranges that are inherently less efficient to process and transfer than a 
single range that encompasses the same data."

..or it can serve the response as multipart/byteranges as requested.

> It is unusual to have a RFC 2119 requirement defined in an appendix.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/505>

> I don't understand why the RFC 2119 "should" is used in the above.  When
> can the "should" be ignored?  Is the server supposed to generate the

Dunno.

> same Content-Type header field in each header area if the selected
> representation would have a Content-Type header field for a 200 (OK)
> response?

That's what the above says, no?

> It is recommended in the Section 3.1 that the client lists the ranges it
> requests in ascending order.  The above text recommends that the server
> should send the parts in the same order as the request.  There can be an
> interoperability issue when the two sides are told to do RFC 2119 "should".

Such as?

> The request to IANA should be in the IANA Considerations section.

Right. Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2441>.

> As the word "OPTIONAL" in the above is not interpreted according to RFC
> 2119 I suggest using plain English instead of a word in uppercase.

It is supposed to be interpreted per RFC 2119.

> conversation issues in the reviews.  I suggest doing a verification to
> verify that there is adequate text where it is applicable.

Raised as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/507>.

> ..

Best regards, Julian

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Oct 2013 01:38:30 -0700

Hi Julian,
At 08:03 29-10-2013, Julian Reschke wrote:
>Actually, it was a case of "this is used in the wild already, and 
>more use is coming up, so better document it properly and add the 
>registry". See 
><http://trac.tools.ietf.org/wg/httpbis/trac/ticket/85> for the history.

Thanks.  I'll consider this as addressed.

I gather that the working group is leaving what can registered as a 
range unit to IETF Review instead of providing specific guidance.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Oct 2013 00:46:51 -0700

Hi Julian,
>thanks a lot for the incoming reviews! I'm tracking them in the WG's 

Ok.  As you understand how things work I'll defer to you on the 
issues instead of tracking down what has been addressed.

>overhead to GET responses, even though only few clients will make 
>range requests.

Ok.

>Yes. Do you think this is a problem? Why?

It's the kind of text which generates long threads outside the 
IETF.  Some people can argue that it is a "may" written in uppercase 
while other people will argue that the plain English says something 
else.  My preference is for the intent of the text to be clear unless 
there is a good reason not to be clear.

><http://trac.tools.ietf.org/wg/httpbis/trac/ticket/505>

That's applicable to several drafts in the set.

>header field that consists of more than two overlapping ranges, or a 
>set of many small ranges that are not listed in ascending order, 
>since both are indications of either a broken client or a deliberate 
>denial of service attack (Section 6.1). A client SHOULD NOT request 
>multiple ranges that are inherently less efficient to process and 
>transfer than a single range that encompasses the same data."
>

Ok.

>That's what the above says, no?

Ok.

>Such as?

What I mean is that what happens is undefined when both sides do not 
follow the RFC 2119 "should".

>Right. Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2441>.

Ok.

>It is supposed to be interpreted per RFC 2119.

It is better to use the uppercase words after the RFC 2119 boilerplate.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 09:57:02 +0100

> follow the RFC 2119 "should".

The response is self-descriptive, so it's up to the client to properly 
process it.

> It is better to use the uppercase words after the RFC 2119 boilerplate.

But then, we don't want the boilerplate to be in front of the 
Introduction. Any *concrete* suggestion how to address this?

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 30 Oct 2013 08:37:46 -0400

Add a forward reference to the boilerplate after the uppercase word?

On Oct 30, 2013, at 4:57 AM, Julian Reschke <[email-masked]> wrote:

> The response is self-descriptive, so it's up to the client to properly process it.
> 
> But then, we don't want the boilerplate to be in front of the Introduction. Any *concrete* suggestion how to address this?
> 
> Best regards, Julian
> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Oct 2013 14:49:59 -0700

Hi Julian,
>Introduction. Any *concrete* suggestion how to address this?

The sentence about "OPTIONAL feature" can be added to Section 3 of 
draft-ietf-httpbis-p5-range-24.

I would consider adding some text to the paragraph in Section 2.5 of 
draft-ietf-httpbis-p1-messaging-24 about "considered 
conformant".  This is to make it clear which features are part of basic HTTP.

Regards,
S. Moonesamy