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

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: "K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>" <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>>
Date: Thursday, April 21, 2016 at 4:25 AM
To: 'Craig Pratt' <craig@ecaspia.com<mailto:craig@ecaspia.com>>, "fielding@gbiv.com<mailto:fielding@gbiv.com>" <fielding@gbiv.com<mailto:fielding@gbiv.com>>
Cc: "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: RE: Issue with "bytes" Range Unit and live streaming
Resent-From: <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Resent-Date: Thursday, April 21, 2016 at 4:25 AM


On Thursday,21 April 2016 05:18 craig@ecaspia.com<mailto:craig@ecaspia.com> 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.