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

Julian Reschke <julian.reschke@gmx.de> Tue, 29 October 2013 15:28 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9154811E82F0 for <ietf@ietfa.amsl.com>; Tue, 29 Oct 2013 08:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.739
X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Qzw9uZAj5dnR for <ietf@ietfa.amsl.com>; Tue, 29 Oct 2013 08:28:09 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) by ietfa.amsl.com (Postfix) with ESMTP id 9E57111E82CE for <ietf@ietf.org>; Tue, 29 Oct 2013 08:27:41 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MBFBB-1VR2iX0c2H-00AFRY for <ietf@ietf.org>; Tue, 29 Oct 2013 16:27:40 +0100
Message-ID: <526FD3E8.9010904@gmx.de>
Date: Tue, 29 Oct 2013 16:27:36 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org
Subject: #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:lTQ7ihb1WqNXjyqrrUGWEdYFwl7GDMA8u4iSKBccy6X1SdbrQSt gTqhD4hYShp0A5oeURTEXIyYz1/ndT11O7xducgdnRk0rt5J9e/DCHwrxwUhOC/zmpSD3+r /YCIuJA6g4G6MWEthY0UZtVAL5uFHNE6jT309Lgrv3jc4AHRA/KAtMpu4Vv9JyginigObSE Vxf5GBx8J8PieG1S6iliQ==
Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 15:28:09 -0000

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 

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


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


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

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