Opened 9 years ago
Closed 9 years ago
#506 closed design (incorporated)
APPSDIR review of draft-ietf-httpbis-p5-range-24
Reported by: | julian.reschke@… | Owned by: | draft-ietf-httpbis-p5-range@… |
---|---|---|---|
Priority: | normal | Milestone: | 25 |
Component: | p5-range | Severity: | In IETF LC |
Keywords: | Cc: |
Description (last modified by julian.reschke@…)
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. - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html
In Section 3.2:
"HTTP-date" is defined in the Appendix C. I suggest importing the
rules should be in Section 1.2. - see #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. - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html
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. - see #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 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". - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html
In Appendix A:
"The following definition is to be registered with IANA [BCP13]."
The request to IANA should be in the IANA Considerations section. - [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. - see #515
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. - see #507
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. - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html
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. - see [2438]
Change History (15)
comment:1 Changed 9 years ago by julian.reschke@…
- origin changed from http://www.w3.org/mid/6.2.5.6.2.20131028101123.0e37a698@elandnews.comMajor 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. to http://www.w3.org/mid/6.2.5.6.2.20131028101123.0e37a698@elandnews.com
comment:2 Changed 9 years ago by julian.reschke@…
comment:3 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:4 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:5 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:6 Changed 9 years ago by julian.reschke@…
comment:7 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:8 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:9 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:10 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:11 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:12 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:13 Changed 9 years ago by julian.reschke@…
- Description modified (diff)
comment:14 Changed 9 years ago by julian.reschke@…
- Severity changed from In WG Last Call to In IETF LC
comment:15 Changed 9 years ago by julian.reschke@…
- Milestone changed from unassigned to 25
- Resolution set to incorporated
- Status changed from new to closed
From [2438]:
fix typo (see #506)