- From: Plex <rodger.combs@gmail.com>
- Date: Fri, 02 Oct 2015 00:28:25 +0000
- To: HTTP <ietf-http-wg@w3.org>
- Cc: Mark Nottingham <mnot@mnot.net>
I've updated https://datatracker.ietf.org/doc/draft-combs-http-indeterminate-range/ to address some minor formatting issues, and complete the IANA Considerations section. Does anyone have any input on this? > On Jun 29, 2015, at 20:28, Plex <rodger@plexapp.com> wrote: > > It's been a while since this thread has seen any movement; anyone have any suggestions on how to move forward on this? > >> On Apr 8, 2015, at 04:43, Mark Nottingham <mnot@mnot.net> wrote: >> >> I did a fairly quick cut-n-paste; feel free to correct/elaborate in the bugs. >> >> Cheers, >> >> >>> On 8 Apr 2015, at 5:25 pm, Rodger Combs <rodger@plexapp.com> wrote: >>> >>> Some of the ticket descriptions there are incorrect. libavformat's strncmp() approach only matches if the _first_ 5 characters match "bytes", WebKit's g_ascii_strcasecmp only matches if the entire header is exactly "none", Gecko's nsAutoCString::EqualsLiteral only matches if the entire header is exactly "bytes", and Chrome's std::string::find approach works as you described. So they'd all be potentially buggy in different circumstances. >>> >>>> On Apr 8, 2015, at 00:12, Mark Nottingham <mnot@mnot.net> wrote: >>>> >>>> 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/ >>> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >
Received on Friday, 2 October 2015 08:28:32 UTC