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

[Craig Pratt <[e-mail]>]

On 4/18/16 12:34 AM, [e-mail] wrote:

On Friday,15 April 2016 22:43, [e-mail] wrote:

Oh, never mind, now I see that you are referring to the second number being
fixed.

I think I would prefer that be solved by allowing last-byte-pos to be empty, just
like it is for the Range request.  I think such a fix is just as likely to be
interoperable as introducing a special range type (same failure cases).

....Roy

+1000

A very similar idea was proposed before [1] as an I-D [2] by Rodger Coombs. We've also brought this up informally with other members of the WG.

Alas, in our experience range requests don't seem to be a high priority :(  For example, the problem of combining gzip with range requests is still unsolved [3].

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0122.html" rel="nofollow">https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0122.html
[2] https://tools.ietf.org/html/draft-combs-http-indeterminate-range-01" rel="nofollow">https://tools.ietf.org/html/draft-combs-http-indeterminate-range-01
[3] https://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1327.html" rel="nofollow">https://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1327.html

[cp] Yeah, it's unfortunate that no solutions have moved forward for this widely-desired feature. I can only assume that people just started defining proprietary solutions - which is unfortunate. I'll try to be "persistent"... ;^J

[cp] As was mentioned, the issue with just arbitrarily allowing an open-ended Content-Range response (omitting last-byte-pos) is that there's no good way for a client to indicate it can support reception of a Content-Range without a last-byte-pos. So I would fully expect many clients to fail in "unpredictable ways" (disconnecting, crashing, etc).

[cp] I see that the indeterminate length proposal you referenced in your first citation introduces a "Accept-Indefinite-Ranges" header to prevent this issue. But I think this brings with it some other questions. e.g. Would this apply to any/all Range Units which may be introduced in the future? How can a Client issue a request that starts at the "live point"? It feels like it has one hand tied behind its back.

[cp] If I could, I would prefer to go back in time and advocate for an alternate ABNF for the bytes Range Unit. Seeing as that's not an option, I think using this well- and long-defined Range Unit extension mechanism seems like a good path forward as it should not create interoperability issues between clients and servers.

[cp] And I would hope adding a Range Unit would have a low/lower bar for acceptance. e.g. If a Range Unit fills a useful role, is well-defined, and isn't redundant, it seems reasonable that it should be accepted as it shouldn't impact existing HTTP/1.1 semantics. In fact, the gzip case (referenced in your third citation) seems like a perfect application of the Range Unit (better than bytes-live). If there's interest, I'll write up an RFC to demonstrate...

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 [e-mail] 503.746.8008