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