Re: Range Responses of Indeterminate Length: Draft

Michael Sweet <> Tue, 07 April 2015 11:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3C911B347D for <>; Tue, 7 Apr 2015 04:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.802
X-Spam-Status: No, score=-6.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZqyR95B9jLK for <>; Tue, 7 Apr 2015 04:19:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BDED1B3478 for <>; Tue, 7 Apr 2015 04:19:42 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YfRTC-0007vn-SG for; Tue, 07 Apr 2015 11:15:02 +0000
Resent-Date: Tue, 07 Apr 2015 11:15:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YfRT8-0006NJ-GC for; Tue, 07 Apr 2015 11:14:58 +0000
Received: from ([] by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1YfRSz-0005Xq-Tc for; Tue, 07 Apr 2015 11:14:58 +0000
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1428405262; x=2292318862; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lLZ4woCP4l2rSCYQWYPqmFjnJO7cUBiaUvWHCbi9plY=; b=3+PT/iJ6rVTI3VOdhDJAlEiZlQ3X4RgTuasswxxXGLBLL7zScsOOFedkNXFvIcub bueW2t3cqwkElKg5IFt5H5PKj4QzW+uA0C3OEnCsILSN8m7OetOQwM+HZjJhKs1w UPfZnSXWBN8hL+4RSseKPoEe6S/jkrbi0xKMgDAbiYacqp9QSU0BftIUDkYcP7qw lQ4FvCFdqsZTAPfo5c2pRZ95QWjDlzfmnTdD4XuPngjOgioK9SKMN9nsQb482nDU FfgYs24EBWu3DI/hxxVm1rBzk/x+m4suweKWg4qZg9GXTxs/g0LMIa5VP+BLDZpy q4tU3CHTe6lsCHc8RY8jsg==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 4D.7B.12430.E0CB3255; Tue, 7 Apr 2015 04:14:22 -0700 (PDT)
X-AuditID: 11973e13-f79d56d00000308e-bb-5523bc0e6eac
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id 63.5C.19589.61CB3255; Tue, 7 Apr 2015 04:14:30 -0700 (PDT)
Received: from [] by (Oracle Communications Messaging Server 64bit (built Oct 22 2013)) with ESMTPSA id <> for; Tue, 07 Apr 2015 04:14:22 -0700 (PDT)
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-type: text/plain; charset="utf-8"
From: Michael Sweet <>
In-reply-to: <>
Date: Tue, 07 Apr 2015 07:14:20 -0400
Cc: Rodger Combs <>, HTTP Working Group <>
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYrMu3RznU4OVkPYvDLbOYHBg9js7b zxrAGMVlk5Kak1mWWqRvl8CVcWHxDaaCyUIV2y43sTYw/uTrYuTkkBAwkbg+5wgLhC0mceHe erYuRi4OIYG9jBI7HzWywRQ9O3WcHSIxkUni4dE9jBDOX0aJp3O+gLULC1hLzNq6jR3E5hXQ k5hzfQFQNwcHs4C6xJQpuSBhNgE1id+T+lhBbE4BG4m1/26BtbIIqEpMvPSNCcRmFvCXWPlt OTOErS3x5N0FVoiRNhKLF54Bs4UEciRevD4KVi8ioCzxff4SFpBVEgKyEl+3yoGcJiHwkVXi yeNLjBMYhWchuWgWwkWzkGxYwMi8ilEoNzEzRzczz1QvsaAgJ1UvOT93EyMoiKfbCe9gPL3K 6hCjAAejEg8vg5xyqBBrYllxZe4hRmkOFiVxXrXDSqFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGJtblGp+7pqwc1LrJNfVItsv6wa6zP1svJD3jXrE2WSG5W46qsXejbOs784oTTgaUTfr cWec87LX9pVX9QO3CrdOWFuhUrVEkDuzOvCs9Mf+0wc8dwr8Xak+31M7k1v6xoLEj9obVyxm NXLa22dk97J22uH1xQFfzoSd27jfexJ/gGSUwD+tpUosxRmJhlrMRcWJAN9qtChDAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAcpyu2RznU4OoMdYvDLbOYHBg9js7b zxrAGMVlk5Kak1mWWqRvl8CVcWHxDaaCyUIV2y43sTYw/uTrYuTkkBAwkXh26jg7hC0mceHe erYuRi4OIYGJTBIPj+5hhHD+Mko8nfOFBaRKWMBaYtbWbWAdvAJ6EnOuLwDq4OBgFlCXmDIl FyTMJqAm8XtSHyuIzSlgI7H23y2wVhYBVYmJl74xgdjMAv4SK78tZ4awtSWevLvACjHSRmLx wjNgtpBAjsSL10fB6kUElCW+z1/CArJKQkBW4utWuQmMArOQHDEL4YhZSIYuYGRexShQlJqT WGmsl1hQkJOql5yfu4kRHHSFwTsY/yyzOsQowMGoxMPLIKccKsSaWFZcmXuIUYKDWUmEt3En UIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvjrBSqJBAemJJanZqakFqEUyWiYNTqoFx++zNzspd S3k0pXZNunxmef5bjntLv2/ZI6GW1mjL02NTY7ArO2/vLZnOb+9qzI3ibl35r3cv6/fsw6vv q/x86pd04dPWm3ejGadzJmzN4GSTui92vWj+hbdyd62anh02uJ8R/H9jzdPd8Svk95uzvM3t XfXc7tWnaWs3x1rZe3E8qdfd/uHYNCWW4oxEQy3mouJEAJtZsOM2AgAA
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-0.384, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YfRSz-0005Xq-Tc 85a31a61b8e8de2c0dc12c4a69663a64
Subject: Re: Range Responses of Indeterminate Length: Draft
Archived-At: <>
X-Mailing-List: <> archive/latest/29286
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Have you looked at:

> On Apr 7, 2015, at 1:24 AM, Mark Nottingham <> wrote:
> Hi Roger,
> There are a bunch of folks talking about how to do streaming (especially video) over HTTP, and byte ranges often come up as a mechanism. This reminds me of a discussion we briefly had at the end of the Dallas meeting, where some folks wanted to use byte ranges for sparse content in MPEG DASH.
> I think the concerns I had there apply here too; by overloading/changing the partial content mechanism, you’re risking interoperability problems with deployed infrastructure — especially proxy/caches, which can and do cache partial responses, generate partial requests, etc.
> For example, if there’s a caching proxy in the middle that doesn’t understand Accept-Indefinite-Ranges, it’ll pass it through unmodified, and the server will then potentially generate 206 responses that are malformed.
> This and many similar discussions I’ve had recently makes me wonder whether it’d be interesting to define a genuinely new partial content mechanism that’s tailored for media streaming; while it would depend on intermediaries rolling out support for the new mechanism to get any benefit from them, at least we could design it so that it doesn’t interact badly with deployed intermediaries.
> What do people (especially intermediary implementers) think?
> Cheers,
>> On 6 Apr 2015, at 10:17 pm, Rodger Combs <> wrote:
>> Hello!
>> I've written up a draft standard for an HTTP extension that allows range requests to work more effectively with resources of indeterminate length. I've submitted it as an Internet-Draft, and wondered if anyone had any suggestions as to how to improve it, or move it towards standardization?
>> Thanks,
>> --Rodger
> --
> Mark Nottingham

Michael Sweet, Senior Printing System Engineer, PWG Chair