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