Re: Range Responses of Indeterminate Length: Draft

Mark Nottingham <> Tue, 07 April 2015 05:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D98A21B2A24 for <>; Mon, 6 Apr 2015 22:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mjjl1ZeLEiGY for <>; Mon, 6 Apr 2015 22:28:36 -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 43AF21A0151 for <>; Mon, 6 Apr 2015 22:28:36 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YfM0H-0006df-H4 for; Tue, 07 Apr 2015 05:24:49 +0000
Resent-Date: Tue, 07 Apr 2015 05:24:49 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YfM0D-0006cy-8O for; Tue, 07 Apr 2015 05:24:45 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1YfM0B-0006dG-UR for; Tue, 07 Apr 2015 05:24:45 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D955722E261; Tue, 7 Apr 2015 01:24:19 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 07 Apr 2015 15:24:17 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Rodger Combs <>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.3
X-W3C-Hub-Spam-Report: AWL=0.353, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1YfM0B-0006dG-UR bedf785dcb44421d1868b39e0bbe79fd
Subject: Re: Range Responses of Indeterminate Length: Draft
Archived-At: <>
X-Mailing-List: <> archive/latest/29280
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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?


> 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