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

From: Darshak Thakore <[email-masked]>
Date: Tue, 10 May 2016 19:57:28 +0000

Hi all,

Based on feedback on this thread, it seems like the need for being able to send an open ended (read as unknown-last-byte-pos) Range response has been discussed a couple of times (with different use cases). Also there seems to be somewhat general agreement that the Content-Range ABNF in RFC 7233 is deficient in providing this. The initial argument has been, “is there a compelling enough need” and i think with different use cases popping up (log files, media streaming, gzip… others ??) there seems to be some value in defining a non-application specific Range unit that plugs this gap. Clearly fixing RFC 7233 is invasive and will result in thing breaking in unknown ways so that’s a no-go. With that, we can:

  1.  Ensure that the scope of this work item is narrow and restricted only to fixing the gap in RFC 7233
  2.  Define a new range unit (anything with “bytes” in it seems like a bad idea, so maybe call it “live-octets”, “blive”, “b-add" - suggestions welcome….)
  3.  Decide if there is enough interest/reason to do this as a WG item

Any objects/suggestions to any of the above ?

Regards,
Darshak

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 21, 2016 at 4:25 AM
To: 'Craig Pratt' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Issue with "bytes" Range Unit and live streaming
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, April 21, 2016 at 4:25 AM

On Thursday,21 April 2016 05:18 [email-masked]<mailto:[email-masked]> wrote:

> Re: Representation caching

> Whether a representation is considered cacheable in this use case is at

> the discretion of the origin server and specific to the use

> case/application - as it should be (imho). There's no *necessity* in

> having a periodically-appended resource marked non-cachable, correct? If

> the resource mutates, it's not cacheable. If it's just being appended

> to, it is cacheable. And if an appended resource stops being appended

> to, it doesn't invalidate the cached representation.

I couldn't agree more. However, it seemed the prevailing sentiment when we tried to resolve the related issue of ranges before content codings, with a new bbcc unit (bytes-before-content-coding), was that the use cases for append-only growth represent an insignificant portion of HTTP traffic. “We live by app-specific protocols to handle these cases. What is so special ... that it must be addressed by http (in a very ugly way)?” [1]

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1383.html

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 May 2016 10:59:25 +1000

Hi Darshak,

I don't think that's where we're at. Based on the discussion so far, it seems like there are two possible paths forward:

1. Changing the 'bytes' range-unit to allow this use case
2. Minting a new range-unit

As discussed, both have downsides. What we need is data about how current implementations -- especially caching intermediaries -- behave when faced with a) 'bytes' used in the desired way, and b) a new range-unit.

Cheers,

> On 11 May 2016, at 5:57 AM, Darshak Thakore <[email-masked]> wrote:
> 
> Hi all,
> 
> 	• Ensure that the scope of this work item is narrow and restricted only to fixing the gap in RFC 7233
> 	• Define a new range unit (anything with “bytes” in it seems like a bad idea, so maybe call it “live-octets”, “blive”, “b-add" - suggestions welcome….)
> 	• Decide if there is enough interest/reason to do this as a WG item
> From: "[email-masked]" <[email-masked]>
> To: 'Craig Pratt' <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Resent-From: <[email-masked]>
> On Thursday,21 April 2016 05:18 [email-masked] wrote: 
> > 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 May 2016 01:16:36 +0000

unless we allow Content-Length to also use the new unit (which I'd be 
dead against), I'd suggest we steer clear of minting any new range 
units.

All the proposed use cases for new range units that I've seen are 
application specific, and could arguably better be dealt with using 
another header.

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Darshak Thakore" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 12/05/2016 12:59:25 p.m.
Subject: Re: Issue with "bytes" Range Unit and live streaming

>Hi Darshak,
>
>I don't think that's where we're at. Based on the discussion so far, it 
>seems like there are two possible paths forward:
>
>As discussed, both have downsides. What we need is data about how 
>current implementations -- especially caching intermediaries -- behave 
>when faced with a) 'bytes' used in the desired way, and b) a new 
>range-unit.
>
>Cheers,
>
>
>>  Based on feedback on this thread, it seems like the need for being 
>>able to send an open ended (read as unknown-last-byte-pos) Range 
>>response has been discussed a couple of times (with different use 
>>cases). Also there seems to be somewhat general agreement that the 
>>Content-Range ABNF in RFC 7233 is deficient in providing this. The 
>>initial argument has been, “is there a compelling enough need” and i 
>>think with different use cases popping up (log files, media streaming, 
>>gzip… others ??) there seems to be some value in defining a 
>>non-application specific Range unit that plugs this gap. Clearly 
>>fixing RFC 7233 is invasive and will result in thing breaking in 
>>unknown ways so that’s a no-go. With that, we can:
>>   • Define a new range unit (anything with “bytes” in it seems like a 
>>bad idea, so maybe call it “live-octets”, “blive”, “b-add" - 
>>suggestions welcome….)
>>  I couldn't agree more. However, it seemed the prevailing sentiment 
>>when we tried to resolve the related issue of ranges before content 
>>codings, with a new bbcc unit (bytes-before-content-coding), was that 
>>the use cases for append-only growth represent an insignificant 
>>portion of HTTP traffic. “We live by app-specific protocols to handle 
>>these cases. What is so special ... that it must be addressed by http 
>>(in a very ugly way)?” [1]
>>
>>  [1] 
>>https://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1383.html
>>
>>
>>
>>  This email message is intended only for the use of the named 
>>recipient. Information contained in this email message and its 
>>attachments may be privileged, confidential and protected from 
>>disclosure. If you are not the intended recipient, please do not read, 
>>copy, use or disclose this communication to others. Also please notify 
>>the sender by replying to this message and then delete it from your 
>>system.
>
>--

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 May 2016 11:40:28 +1000

> 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.)

---

From: Craig Pratt <[email-masked]>
Date: Wed, 11 May 2016 19:01:39 -0700

Reply in-line.

cp

On 5/11/16 6:16 PM, Adrien de Croy wrote:
> dead against), I'd suggest we steer clear of minting any new range units.
>
[cp] I don't see how a Range Unit would apply to Content-Length.

Regardless of how a range is requested, the server is always 
transferring bytes in the response body - whether indicated by 
Content-Length, chunks, or whatever. The Content-Range response header 
just lets the server indicate the returned range associated with the 
response body *in terms of the indicated range unit* and *in the domain 
of the representation*.

e.g. If a Range Unit called "blobs" is used, and a request is made with 
"Range: blobs=5-11", the response could have header "Content-Range: 
blobs=5-11/50" indicating that 7 blobs are being returned (out of 50) in 
the response body and a "Content-Length: 123456" could also be supplied 
designating that the response body (associated with blobs 5-11) is 
123456 bytes.

Am I missing something?

> application specific, and could arguably better be dealt with using 
[cp] Doesn't the fact that there's a Range Unit Registry mean that Range 
Units can be added that are application-specific - assuming there's 
sufficient demand? It's just a different mechanism than adding custom 
headers, IMHO - with well-defined semantics.

>> I don't think that's where we're at. Based on the discussion so far, 
>> it seems like there are two possible paths forward:
>>
>> current implementations -- especially caching intermediaries -- 
>> behave when faced with a) 'bytes' used in the desired way, and b) a 
>> new range-unit.
>>
>> Cheers,
>>
>>
>>> think with different use cases popping up (log files, media 
>>> streaming, gzip… others ??) there seems to be some value in defining 
>>> a non-application specific Range unit that plugs this gap. Clearly 
>>>   • Define a new range unit (anything with “bytes” in it seems like 
>>> a bad idea, so maybe call it “live-octets”, “blive”, “b-add" - 
>>> suggestions welcome….)
>>> codings, with a new bbcc unit (bytes-before-content-coding), was 
>>> that the use cases for append-only growth represent an insignificant 
>>> portion of HTTP traffic. “We live by app-specific protocols to 
>>> handle these cases. What is so special ... that it must be addressed 
>>> by http (in a very ugly way)?” [1]
>>>
>>>  [1] 
>>> disclosure. If you are not the intended recipient, please do not 
>>> read, copy, use or disclose this communication to others. Also 
>>> please notify the sender by replying to this message and then delete 
>>> it from your system.
>>
>> -- 

-- 

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

---

From: Craig Pratt <[email-masked]>
Date: Wed, 11 May 2016 19:19:12 -0700

> reason that isn't feasible?  (There are probably many, but I saw none
I'm definitely OK with a third option.

If no one thinks it's safe to define new Range Units, perhaps the 
"Range" and "Content-Range" ABNF can have the ability to express 
non-"bytes" Range Units removed and a new header can be defined which 
has the same semantics, produces a Partial Content response, references 
the Unit Range registry and won't hose up proxies and other entities 
that aren't coded to deal with something other than "bytes" or "none" in 
"Accept-Range"?

e.g. "Range-Units-Accepted" and "Range-Unit" headers could be defined...

cp

-- 

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 May 2016 02:55:42 +0000

------ Original Message ------
From: "Craig Pratt" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 12/05/2016 2:01:39 p.m.
Subject: Re: Issue with "bytes" Range Unit and live streaming

>[cp] I don't see how a Range Unit would apply to Content-Length.
yes. That's the problem.

And that's why suggestions for alternative range units keep cropping up.

If you're an intermediate that has no knowledge of pages or frames, it's 
impossible to comply with any other range than bytes.

It's not hard to ask for

GET something?page=1

Which is cachable, vs making life impossible for intermediaries.

Adrien

>blobs=5-11/50" indicating that 7 blobs are being returned (out of 50) 
>in the response body and a "Content-Length: 123456" could also be 
>supplied designating that the response body (associated with blobs 
>5-11) is 123456 bytes.
>
>Am I missing something?
>
>[cp] Doesn't the fact that there's a Range Unit Registry mean that 
>Range Units can be added that are application-specific - assuming 
>there's sufficient demand? It's just a different mechanism than adding 
>custom headers, IMHO - with well-defined semantics.
>
>>
>>
>>>-- Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>
>>
>
>
>--
>craig pratt
>
>Caspia Consulting
>
>[email-masked]
>
>503.746.8008
>
>
>
>
>
>
>
>
>

---

From: Craig Pratt <[email-masked]>
Date: Wed, 11 May 2016 20:37:14 -0700

On 5/11/16 7:55 PM, Adrien de Croy
wrote:

------ Original Message ------

Reply in-line.

cp

unless we allow Content-Length to also use the new unit (which
I'd be dead against), I'd suggest we steer clear of minting
any new range units.

yes. That's the problem.

And that's why suggestions for alternative range units keep
cropping up.

If you're an intermediate that has no knowledge of pages or
frames, it's impossible to comply with any other range than bytes.

It's not hard to ask for

GET something?page=1

Adrien

[cp] This is not a good solution for large representations.

There's no way for a cache to know that "GET something?pages=1-10"
has some of the same content that "GET something?pages=2-11" since
it doesn't (can't) have any understanding of the URI params. So
you'll end up with two copies of pages 2-10 in the cache.

And at the same time, the cache can't service a request of the form
"GET something?page=3" for the same reason - even though you would
have 2 copies of page 3 in the cache. The request will go to the
origin and you'll now have 3 copies of page 3 in the cache.

Obviously, an application can define it's own request header and
mark the response data non-cacheable. And this would still be better
than the above. But what I would rather do is ensure that any Range
Units that are defined include a bytes range that would at least
*allow* for caching. A Vary can probably take care of preventing the
kind of cache problems like those described above - given a little
thought... I'll try to write up something concrete.

Regardless of how a range is requested, the server is always
transferring bytes in the response body - whether indicated by
Content-Length, chunks, or whatever. The Content-Range response
header just lets the server indicate the returned range
associated with the response body *in terms of the indicated
range unit* and *in the domain of the representation*.

e.g. If a Range Unit called "blobs" is used, and a request is
made with "Range: blobs=5-11", the response could have header
"Content-Range: blobs=5-11/50" indicating that 7 blobs are being
returned (out of 50) in the response body and a "Content-Length:
123456" could also be supplied designating that the response
body (associated with blobs 5-11) is 123456 bytes.

Am I missing something?

All the proposed use cases for new range
units that I've seen are application specific, and could
arguably better be dealt with using another header.

Adrien

[cp] Doesn't the fact that there's a Range Unit Registry mean
that Range Units can be added that are application-specific -
assuming there's sufficient demand? It's just a different
mechanism than adding custom headers, IMHO - with well-defined
semantics.

------ Original Message ------

Hi Darshak,

I don't think that's where we're at. Based on the discussion
so far, it seems like there are two possible paths forward:

As discussed, both have downsides. What we need is data
about how current implementations -- especially caching
intermediaries -- behave when faced with a) 'bytes' used in
the desired way, and b) a new range-unit.

Cheers,

On 11 May 2016, at 5:57 AM, Darshak
Thakore <[email-masked]> wrote:

Hi all,

Based on feedback on this thread, it seems like the need
for being able to send an open ended (read as
unknown-last-byte-pos) Range response has been discussed a
couple of times (with different use cases). Also there
seems to be somewhat general agreement that the
Content-Range ABNF in RFC 7233 is deficient in providing
this. The initial argument has been, “is there a
compelling enough need” and i think with different use
cases popping up (log files, media streaming, gzip… others
??) there seems to be some value in defining a
non-application specific Range unit that plugs this gap.
Clearly fixing RFC 7233 is invasive and will result in
thing breaking in unknown ways so that’s a no-go. With
that, we can:

• Ensure that the scope of this work item is narrow and
restricted only to fixing the gap in RFC 7233

• Define a new range unit (anything with “bytes” in it
seems like a bad idea, so maybe call it “live-octets”,
“blive”, “b-add" - suggestions welcome….)

• Decide if there is enough interest/reason to do this
as a WG item

Regards,

Darshak

To: 'Craig Pratt' <[email-masked]>,
"[email-masked]" <[email-masked]>

Subject: RE: Issue with "bytes" Range Unit and live
streaming

On Thursday,21 April 2016 05:18 [email-masked] wrote:

I couldn't agree more. However, it seemed the prevailing
sentiment when we tried to resolve the related issue of
ranges before content codings, with a new bbcc unit
(bytes-before-content-coding), was that the use cases for
append-only growth represent an insignificant portion of
HTTP traffic. “We live by app-specific protocols to handle
these cases. What is so special ... that it must be
addressed by http (in a very ugly way)?” [1]

[1]

This email message is intended only for the use of the
named recipient. Information contained in this email
message and its attachments may be privileged,
confidential and protected from disclosure. If you are not
the intended recipient, please do not read, copy, use or
disclose this communication to others. Also please notify
the sender by replying to this message and then delete it
from your system.

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 May 2016 03:47:19 +0000

------ Original Message ------
From: "Craig Pratt" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 12/05/2016 3:37:14 p.m.
Subject: Re: Issue with "bytes" Range Unit and live streaming

>On 5/11/16 7:55 PM, Adrien de Croy wrote:
>>
>>
>>From: "Craig Pratt" mailto:[email-masked]
>>To: mailto:[email-masked]:[email-masked]
>>>>unless we allow Content-Length to also use the new unit (which I'd 
>>>>be dead against), I'd suggest we steer clear of minting any new 
>>>>range units.
>>>>
>>If you're an intermediate that has no knowledge of pages or frames, 
>>it's impossible to comply with any other range than bytes.
>>
>>It's not hard to ask for
>>
>>GET something?page=1
>>
>There's no way for a cache to know that "GET something?pages=1-10" has 
>some of the same content that "GET something?pages=2-11" since it 
>doesn't (can't) have any understanding of the URI params. So you'll end 
>up with two copies of pages 2-10 in the cache.

the problem is that fundamentally without some form of mapping between 
whatever other range units would be used, and bytes (e.g. a table of 
contents), then the intermediary can't resolve a range request and would 
have to reject it (return the entire resource).

Maybe the table of contents should be requested separately (or it should 
form the start of the data).  then the client can just request ranges in 
bytes.

Or maybe define a new multipart response type that includes a 
proxy-readable table of contents to map the parts of the payload.

Otherwise you'll find caching just ends up getting suppressed.

Adrien

>"GET something?page=3" for the same reason - even though you would have 
>2 copies of page 3 in the cache. The request will go to the origin and 
>you'll now have 3 copies of page 3 in the cache.
>
>Obviously, an application can define it's own request header and mark 
>the response data non-cacheable. And this would still be better than 
>the above. But what I would rather do is ensure that any Range Units 
>that are defined include a bytes range that would at least *allow* for 
>caching. A Vary can probably take care of preventing the kind of cache 
>problems like those described above - given a little thought... I'll 
>try to write up something concrete.
>>
>>>
>>>header just lets the server indicate the returned range associated 
>>>with the response body *in terms of the indicated range unit* and *in 
>>>the domain of the representation*.
>>>
>>>e.g. If a Range Unit called "blobs" is used, and a request is made 
>>>with "Range: blobs=5-11", the response could have header 
>>>123456" could also be supplied designating that the response body 
>>>(associated with blobs 5-11) is 123456 bytes.
>>>
>>>Am I missing something?
>>>
>>>there's sufficient demand? It's just a different mechanism than 
>>>adding custom headers, IMHO - with well-defined semantics.
>>>
>>>>
>>>>
>>>>From: "Mark Nottingham" mailto:[email-masked]
>>>>To: "Darshak Thakore" mailto:[email-masked]
>>>>Cc: mailto:[email-masked]:[email-masked]
>>>>>I don't think that's where we're at. Based on the discussion so 
>>>>>far, it seems like there are two possible paths forward:
>>>>>
>>>>>>  On 11 May 2016, at 5:57 AM, Darshak Thakore 
>>>>>>mailto:[email-masked] wrote:
>>>>>>
>>>>>>  Hi all,
>>>>>>
>>>>>>  Based on feedback on this thread, it seems like the need for 
>>>>>>being able to send an open ended (read as unknown-last-byte-pos) 
>>>>>>Range response has been discussed a couple of times (with 
>>>>>>different use cases). Also there seems to be somewhat general 
>>>>>>agreement that the Content-Range ABNF in RFC 7233 is deficient in 
>>>>>>providing this. The initial argument has been, “is there a 
>>>>>>compelling enough need” and i think with different use cases 
>>>>>>popping up (log files, media streaming, gzip… others ??) there 
>>>>>>seems to be some value in defining a non-application specific 
>>>>>>Range unit that plugs this gap. Clearly fixing RFC 7233 is 
>>>>>>invasive and will result in thing breaking in unknown ways so 
>>>>>>that’s a no-go. With that, we can:
>>>>>>   • Define a new range unit (anything with “bytes” in it seems 
>>>>>>like a bad idea, so maybe call it “live-octets”, “blive”, “b-add" 
>>>>>>- suggestions welcome….)
>>>>>>  From: mailto:[email-masked]:[email-masked]
>>>>>>  To: 'Craig Pratt' mailto:[email-masked], 
>>>>>>mailto:[email-masked]:[email-masked]
>>>>>>  Cc: mailto:[email-masked]:[email-masked]
>>>>>>  Resent-From: mailto:[email-masked]
>>>>>>sentiment when we tried to resolve the related issue of ranges 
>>>>>>before content codings, with a new bbcc unit 
>>>>>>append-only growth represent an insignificant portion of HTTP 
>>>>>>traffic. “We live by app-specific protocols to handle these cases. 
>>>>>>What is so special ... that it must be addressed by http (in a 
>>>>>>very ugly way)?” [1]
>>>>>>
>>>>>>  [1] 
>>>>>>please notify the sender by replying to this message and then 
>>>>>>delete it from your system.
>>>>>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 May 2016 06:35:40 +0200

On 2016-05-12 04:19, Craig Pratt wrote:
> ...

FTR: I remain unconvinced that new we can't define new range units. Yes, 
intermediaries will not know hot to handle them (and thus must fall back 
to returning the full resource=), but that doesn't have to always be a 
problem, in particular with https.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 May 2016 14:42:23 +1000

On 12 May 2016, at 2:35 PM, Julian Reschke <[email-masked]> wrote:
> FTR: I remain unconvinced that new we can't define new range units. Yes, intermediaries will not know hot to handle them (and thus must fall back to returning the full resource=), but that doesn't have to always be a problem, in particular with https.

We've seen evidence that some implementations have been hard-wired to assume "bytes." It's not clear how widespread this is.

Cheers,

---

From: Craig Pratt <[email-masked]>
Date: Fri, 20 May 2016 13:17:23 -0700

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 4/20/16 6:11 AM, Martin Thomson wrote:
> On 20 April 2016 at 17:50, Mark Nottingham <[email-masked]> 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

[email-masked]

503.746.8008