Re: bandwidth conservation use case, objection to use of Range for non-byte sections

On 9 March 2010 18:09, Silvia Pfeiffer <> wrote:
> On Tue, Mar 9, 2010 at 7:51 PM, Conrad Parker <> wrote:
>> On 9 March 2010 17:37, Yves Lafon <> wrote:
>>> On Tue, 9 Mar 2010, Conrad Parker wrote:
>>>> Hi,
>>>> I would like to introduce a use cases that is not covered by the
>>>> existing specification: that a user agent may wish to retrieve a media
>>>> resource in chunks, so that the amount of content buffered ahead of
>>>> the user's current play position does not grow too large.
>>>> In order to handle this use case, i propose to introduce a new HTTP
>>>> Request and Response header pair. Following the naming of yesterday's
>>>> F2F discussions, these could be Range-Equivalent and
>>>> Content-Range-Equivalent; they could similarly be part of whatever
>>>> Fragment and Content-Fragment are now being called. Let's call it Foo.
>>>> The syntax would be as has been suggested for non-byte dimensions of
>>>> Range/Content-Range.
>>>> Then, a user agent wishing to retrieve the first 10kB of the resource
>>>>,20 would translate this into:
>>>> Range: bytes=0-10000
>>>> Foo: t:npt=10-20
>>>> An origin server would respond with:
>>>> Content-Range: bytes 0-10000/*
>>>> Content-Foo: t:npt 10-20/0-75
>>>> Vary: Content-Foo
>>> Does it mean that you are 100% sure that the time interval will match to the
>>> byte the byte interval?
>> No, I don't expect that and it is not relevant.
>>> Your use case is better addressed through heuristics and using only byte
>>> ranges. (with some part of decoding, you can infer the average amount of
>>> bytes for some amount of time).
>> That would address a different concern. Here I'm simply talking about
>> transferring the data for 10-20s a few kB at a time.
>> Conrad.
>>>> The use of a header other than Range for non-byte sections has various
>>>> advantages:
>>>> 1. As a consequence, an existing, HTTP/1.1 compliant intermediate
>>>> caching proxy would cache this response and could re-use it when
>>>> providing all or part of a subsequent request for
>>>>,20. For example, the response
>>>> containing only the first 5kB of the resource would be:
>>>> Content-Range: bytes 0-5000/*
>>>> Content-Foo: t:npt 10-20/0-75
>>>> Vary: Content-Foo
>>>> Such a caching proxy would separately cache parts of the response
>>>> generated by the origin server for
>>>>,40 as indicated by the Vary header.
>>>> 2. This mechanism can be used in cases where the client specifies only
>>>> "Accept-Ranges: bytes" (ie. all current browsers and proxies)
>>>> 3. Only the media-related URL translation parts of user agents and web
>>>> servers would require modification to support this mechanism; whereas
>>>> if a new Range dimension is introduced, the transport portions of web
>>>> servers, the caching portion of user agents, and the caching portion
>>>> (ie. all) of caching proxies and content distribution networks would
>>>> need to be re-implemented to allow such ranges to be cached.
>>>> Semantically, I see the Foo header as describing a desired
>>>> representation (much like language handling), but Range has a
>>>> lower-level function related to transport and caching. I think it is
>>>> useful to allow both concerns to be handled by HTTP, which is
>>>> difficult if Range is overloaded.
>>>> I think it is useful to agree on a specification that meets the aims
>>>> of this working group without requiring all WWW implementations to be
>>>> rewritten. Hence I object strongly to
>>>> and instead suggest the use of this minor variation that does not
>>>> overload the existing Range/Content-Range transport mechanism.
>>>> Concerning the process of resolutions: I was not present for that
>>>> resolution as it was after midnight here, and had already raised this
>>>> objection and suggestion during the teleconf prior to its discussion.
> I think I am starting to understand: what if we want to do what all
> the browser vendors do: download a resource successively? But we only
> want to do it for a specific fragment?

Right, that's the general issue.

> I would think the byte ranges should actually be enough for that - the
> UA can administer what fragment it needs. No?

I think you are implying the case where a UA can seek on a single
media resource by byte ranges (by itself, without instructions from
the server). That is not the general case as it is media-type
specific, and in such a case we would not be using any form of time
range request headers so that case is moot.

I'm suggesting that in the case where a UA wants to use HTTP headers
to request a temporal or spatial representation, an HTTP request
header other than Range is used to specify that, in order that Range
can be used for partial retrieval.


Received on Tuesday, 9 March 2010 09:18:19 UTC