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

Yes, in general, though I was considering the specific use cases for which a live stream is a viable response to a range request. For example, I would expect a live stream to be marked as non-cacheable, or at the very least correctly respond to if-match and if-range preconditions. That would prevent any misunderstanding by unaware caches. A live stream request would omit those preconditions.

Likewise, it sounds to me like this bit of protocol would only be used when all components on the chain are aware of the nature of the content and desiring such streaming, since there are just too many non-HTTP factors needed to make it work. IOW, I would not expect the client to allow the request to be proxied unless it already knew the proxy could cooperate.

Nevertheless, there is no hurry in adopting one proposal or another. It should be tested in practice first. 

....Roy


> On Apr 19, 2016, at 12:19 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> On 16 Apr 2016, at 6:42 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>> 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).
> 
> IIRC the issue is that the failure case for a cache -- especially in an intermediary -- is not so simple; if Content-Range parsing fails and something gets stored, the results are unpredictable, and *could* be a lot worse than an unsupported new range-unit (which would just get ignored).
> 
> Historically, we've been shy about changing the semantics or syntax of widely-deployed protocol elements, for the excellent reason that we don't -- and can't -- know all of the implementations, or consequences.
> 
> On the other hand, introducing a new range-unit is expensive; it won't be recognised and taken advantage of in things like proxy caches until they're updated, which we know can take a very long time. Furthermore, Rodger showed us a variety of bugs in existing client implementations that assume that the only range-unit that will ever exist is 'bytes'.
> 
> It would be helpful if we had some data about implementation behaviours regarding these two things (open-ended Content-Range and new range-unit); even if we don't know all of the implementations, we might be able to rule out one (or both) of them based upon practicality. 
> 
> Cheers,
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

Received on Tuesday, 19 April 2016 21:17:28 UTC