Re: Range Responses of Indeterminate Length: Draft
Mark Nottingham <mnot@mnot.net> Wed, 08 April 2015 05:19 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE9F1B3D10 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Apr 2015 22:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je_173xfCxgs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Apr 2015 22:19:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774E21B3D0F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Apr 2015 22:19:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YfiIv-0005MK-0O for ietf-http-wg-dist@listhub.w3.org; Wed, 08 Apr 2015 05:13:33 +0000
Resent-Date: Wed, 08 Apr 2015 05:13:33 +0000
Resent-Message-Id: <E1YfiIv-0005MK-0O@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1YfiIp-0005Ki-DU for ietf-http-wg@listhub.w3.org; Wed, 08 Apr 2015 05:13:27 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1YfiIn-0002HH-LH for ietf-http-wg@w3.org; Wed, 08 Apr 2015 05:13:27 +0000
Received: from [192.168.0.16] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A6A622E261; Wed, 8 Apr 2015 01:13:00 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <3030B260-EAA0-4357-B9F6-3169001EF273@plexapp.com>
Date: Wed, 08 Apr 2015 15:12:57 +1000
Cc: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, HTTP <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>, Bence Béky <bnc@chromium.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <64571D1F-E12B-46D8-B95B-F296C642EE4C@mnot.net>
References: <F755B212-3186-493F-B298-E529A2502467@plex.tv> <DF498B3A-90B7-4D30-88EA-E312B06F9BC4@mnot.net> <55238972.3020108@it.aoyama.ac.jp> <11A96BCA-924D-45C3-B6CA-3653A3470077@mnot.net> <1F073ED1-5F84-4721-9D27-CC07FE0D457C@plexapp.com> <8D499A32-8141-484C-8E96-02222280C0B7@mnot.net> <3030B260-EAA0-4357-B9F6-3169001EF273@plexapp.com>
To: Rodger Combs <rodger@plexapp.com>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-7.4
X-W3C-Hub-Spam-Report: AWL=0.277, 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: maggie.w3.org 1YfiIn-0002HH-LH a14f7d47f9ad379cdb54bcfd5ff104bd
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Range Responses of Indeterminate Length: Draft
Archived-At: <http://www.w3.org/mid/64571D1F-E12B-46D8-B95B-F296C642EE4C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29290
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Thanks! CC:ing a couple of relevant people re: the tickets below. > On 7 Apr 2015, at 6:28 pm, Rodger Combs <rodger@plexapp.com> wrote: > > All links from the mirror most convenient for me: > > libavformat: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/http.c#L583 https://trac.ffmpeg.org/ticket/4451 > Chromium: https://github.com/ChromiumWebApps/chromium/blob/c7361d39be8abd1574e6ce8957c8dbddd4c6ccf7/content/renderer/media/buffered_resource_loader.cc#L399 https://code.google.com/p/chromium/issues/detail?id=474864 > WebKit: https://github.com/WebKit/webkit/blob/4633eb6dd73f925b45244a7f716e571a94f65628/Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp#L860 https://bugs.webkit.org/show_bug.cgi?id=143512 > Firefox: https://github.com/mozilla/gecko-dev/blob/174ec4f7153479c41f6cae2cf58f0a8ac927db0e/dom/media/MediaResource.cpp#L234 https://bugzilla.mozilla.org/show_bug.cgi?id=1152162 > >> On Apr 7, 2015, at 02:54, Mark Nottingham <mnot@mnot.net> wrote: >> >> Do you happen to have references to the specific code in each? Regardless of what we do here, it’d be good to file bugs. >> >> Cheers, >> >> >>> On 7 Apr 2015, at 5:45 pm, Rodger Combs <rodger@plexapp.com> wrote: >>> >>> I strongly considered this (instead of adding a header), but upon looking into existing implementations, it's clear it wouldn't work with existing software. No implementation I checked actually parses `Accept-Ranges` as per the RFC: >>> >>> • libavformat checks if the first 5 characters of the header are "bytes" >>> • Chromium checks if the string "bytes" appears at all >>> • WebKit just checks if it's not equal to "none" >>> • Firefox checks if it's exactly equal to "bytes" >>> >>> That last one makes it impossible to change the header's value without breaking backwards-compatibility with older Firefox versions, and the others are differing degrees of problematic. >>> >>>> On Apr 7, 2015, at 02:39, Mark Nottingham <mnot@mnot.net> wrote: >>>> >>>> That’s what I was thinking. Having said that, I’d want to test some deployed implementations before saying so for sure. >>>> >>>> Cheers, >>>> >>>> >>>>> On 7 Apr 2015, at 5:38 pm, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote: >>>>> >>>>> I haven't studied all of the syntax details, but couldn't using a different unit name, such as "newbytes" (even if it's the same unit as bytes) be made to work? That would avoid the need to deploy a totally new mechanism. >>>>> >>>>> Regards, Martin. >>>>> >>>>> On 2015/04/07 14:24, 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 <rodger@plexapp.com> 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? >>>>>>> https://tools.ietf.org/html/draft-combs-http-indeterminate-range-01 >>>>>>> >>>>>>> Thanks, >>>>>>> --Rodger >>>>>> >>>>>> -- >>>>>> Mark Nottingham https://www.mnot.net/ >>>>>> >>>>>> >>>>>> . >>>>>> >>>> >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>>> >>> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> > -- Mark Nottingham https://www.mnot.net/
- Range Responses of Indeterminate Length: Draft Rodger Combs
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: Range Responses of Indeterminate Length: Draft Martin J. Dürst
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: [Moderator Action] Range Responses of Indeter… Rodger Combs
- Re: [Moderator Action] Range Responses of Indeter… Rodger Combs
- Re: Range Responses of Indeterminate Length: Draft Michael Sweet
- Re: [Moderator Action] Range Responses of Indeter… Rodger Combs
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: [Moderator Action] Range Responses of Indeter… Rodger Combs
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: Range Responses of Indeterminate Length: Draft Plex
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- Re: Range Responses of Indeterminate Length: Draft Rodger Combs
- Re: Range Responses of Indeterminate Length: Draft Plex
- Re: Range Responses of Indeterminate Length: Draft Mark Nottingham
- RE: Range Responses of Indeterminate Length: Draft K.Morgan
- Re: [Moderator Action] Range Responses of Indeter… Amos Jeffries