#506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24

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:
> ...
> 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:

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.

>    "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.

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>

> 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.

"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.

> 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.

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

>    "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

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?

>    "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".

Such as?

> In Appendix A:
>
>    "The following definition is to be registered with IANA [BCP13]."
>
> The request to IANA should be in the IANA Considerations section.

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

> 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.

It is supposed to be interpreted per RFC 2119.

> 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.

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

> ..

Best regards, Julian

Received on Tuesday, 29 October 2013 15:28:09 UTC