Re: Issue with "bytes" Range Unit and live streaming

[Craig Pratt <[e-mail]>]

Hi Martin,

I realized I didn't reply directly to your question - and I mentally 
tangled it up with other ideas that were floating around. Let me try to 
address your question (below).

cp

On 5/11/16 6:40 PM, Martin Thomson wrote:
> On 12 May 2016 at 10:59, Mark Nottingham <[e-mail]> wrote:
>> 1. Changing the 'bytes' range-unit to allow this use case
>> 2. Minting a new range-unit
> I suggested a third option: work around the limitation.  Was there a
> reason that isn't feasible?  (There are probably many, but I saw none
> offered.)
>
On 4/20/16 6:11 AM, Martin Thomson wrote:
> On 20 April 2016 at 17:50, Mark Nottingham <[e-mail]> wrote:
>>> How about "b-live"?
>> Better. If we choose to mint a new range-unit, it might be an opportunity to make other changes too, in which case it might be more generic; that would imply a different, more general name. But we're not there yet.
> Maybe I'm not 100% across the constraints that we're operating with
> here, but is there some way to achieve the basic goal here without
> committing to changes to the protocol?
I guess it depends on one's definition of "changing the protocol". 
Someone can use and define unregistered Range Units today, without 
registering them, and without changing the protocol. But I think I know 
what you're asking.

The only real option clients and servers have had for retrieving 
aggregated resource data (the "basic goal") is to use proprietary 
headers - along with a "Vary" to prevent caches from storing (and 
returning) incorrect content.

But my thinking is that random access a resource's data is fundamental 
to HTTP - and clients shouldn't have to do weird and inefficient things 
just to get a resource's data - even if it's growing. And while there 
are a large number of applications of this today, I think the number of 
applications could be larger over time. Random-access audio and video 
are already huge HTTP applications. And Block Chains (distributed 
financial record keeping) could fit this "aggregated resource" model as 
well. HTTP should be able to handle these simple blobs of data in 
non-application-specific ways, IMHO.

>
> I ask because we have exactly one use of ranges in HTTP and that makes
> me highly skeptical that this particular extension point is actually
> extensible.  As noted up-thread, many implementations make
> assumptions.  That makes the chances that we can successfully make
> changes to the protocol quite slim, or at the very least they could be
> expensive.
>
> If we were to, say, accept that Range is how it is, and concentrated
> on using the protocol as it is to solve the problem, could that work,
> or is there some aspect to the problem that I'm missing?
>
> For example...
>
> If I were to request Range: 123456-* and that resulted in me receiving
> an entirely different response (maybe via redirect) that included the
> requested content with a "This-Is-Part-Of: <that other URL>;
> from=123456", would that work?  Or, and I hesitate to suggest this,
> but it does avoid the extra request... Vary: Range.
When I considered changes to the byte-ranges-specifier, I kept running 
into the same question/problem:

"How would a client know that a server could handle "*" in the 
end-byte-pos field?"

A client might want to operate with a server that would support "*" and 
those that don't. And even if a client tried to determine if it wasn't 
supported, it could make assumptions across resources since a server 
could support "*" on some resources (e.g. continuously updating 
resources) and not on others (e.g. static resources).

And since RFC 7233 doesn't mandate a particular response code to a bytes 
Range request that a server doesn't understand, it's difficult to code a 
client to make good determinations and there will be a performance hit 
to doing so regardless. e.g. Some servers might return 416 to a "*" in 
the end-byte-pos, some might return a different error code, and some 
might just disconnect.

Now, I may not be fully understanding your suggestion (which is why it 
took me a while to respond), but I'm not sure how to get past this same 
hurdle that caused me to abandon the path of changing RFC 7233 and 
looking into other options. But there's more than one way to solve this 
for sure. I just saw Range Units as being a well-defined extension 
mechanism that would allow for a reasonable migration path. e.g. There's 
also https://tools.ietf.org/html/draft-combs-http-indeterminate-range-02.

cp
-- 

craig pratt

Caspia Consulting

[e-mail]

503.746.8008