Subject: Re: Working Group Last Call for HTTP Random Access and Live Content

From: Craig Pratt <[email-masked]>
Date: Sun, 11 Mar 2018 14:44:50 -0700

[Sorry all - been changing jobs this
month - so got behind...]

Thanks much for the thoughts/conversation. Reply in-line.

cp

On 2/16/18 4:46 PM, Matthew Kerwin wrote:

On 17 February 2018 at 06:44, Adrien de Croy <[email-masked]> wrote:

[chomp]

what about a 3rd option

3. Ask the server to send you from a certain timestamp, or "now" not using
byte ranges, but with some other specific attribute of the request that is
deterministic. Does it even need to be a new header, or could it just be a
part of a querystring? Definitely never use Range in any other dimension
than bytes.

This is the the point where you change what is meant by a
representation. If you change the URI, then it's a different
resource, so all existing caching is out the window. Intermediaries
now need to understand your specific REST architecture to optimise
delivery. And if you chuck in a different header you have to put it
in Vary, so it's just as bad.

Yeah, this is how time-seek is handled on time-based representations
in DLNA. This spec defines a "TimeSeekRange.dlna.org" header which
can take a fixed or open-ended time range. Since it's known that a
response body for URI X will be composed of very different data if a
TSR header of "npt=10-20" (seconds) is passed vs an "npt=100-200", a
no-cache/Vary is necessarily included to not confuse proxies.

And as Matthew points out, doing the same via a query param (e.g.
imagine a "timerange=10s-20s" or "timerange=100s-200s") means
they're distinct representations by virtue of having different URIs.

It's definitely a goal of this RFC to try and ensure both client-
and proxy-based caching can still be performed. (fyi, I'm working on
a hopeful fix to the time-shift case as well - should be
forthcoming...)

So I guess I'm overall not convinced there's a need to alter range request
handling. The whole spec seems to be built on an assumption that Range
requests are needed to solve this problem. I would question that. Given
that Range, C-L etc are framing headers, and breaking framing is something
that should not even be considered, due to all the intermediaries out there
that will make this problematic.

Adrien

HTTP is a packet protocol. The only place you can modify a packet
protocol to enable streaming is in the framing. (Something something
encapsulation doesn't seem to be working too well...)

Cheers

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

---

From: Patrick McManus <[email-masked]>
Date: Mon, 12 Mar 2018 07:53:19 +0000 (UTC)

On Sun, Mar 11, 2018 at 5:44 PM, Craig Pratt <[email-masked]> wrote:

>
> It's definitely a goal of this RFC to try and ensure both client- and
> proxy-based caching can still be performed. (fyi, I'm working on a hopeful
> fix to the time-shift case as well - should be forthcoming...)
>
>
>
it sounds like you would like to hold the last call open for another
iteration of the draft?

---

From: Craig Pratt <[email-masked]>
Date: Mon, 12 Mar 2018 01:09:32 -0700

On 3/12/18 12:53 AM, Patrick McManus
wrote:

On Sun, Mar 11, 2018 at 5:44 PM,
Craig Pratt <[email-masked]>
wrote:

It's definitely a goal of this RFC to try and ensure
both client- and proxy-based caching can still be
performed. (fyi, I'm working on a hopeful fix to the
time-shift case as well - should be forthcoming...)

it sounds like you would like to hold
the last call open for another iteration of the draft?

Yeah. In addition to incorporating some editorial changes, we
want to address the issue that Matthew Kerwin brought up related
to the use of Range-less requests on shift-buffer implementations.

We should have a new rev out in the next couple of days.

cp

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008