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

On 17 February 2018 at 06:44, Adrien de Croy <adrien@qbik.com> wrote:
>
>
> I wonder whether what is being proposed to be handled by this is a
> philosophical change for what is meant by a representation.
>
> I guess in the end, my only concerns are that
>
> 1. We don't create unsolvable problems for proxies, or require them to
> change behaviour around byte-ranges (e.g. when it comes to caching or
> framing etc.).
> 2. We have a clear picture of what we are even doing here.  It seems like
> over-loading byte ranges is a hack (large value????).  There should be no
> room for hacks in http.
> 3. It's not clear to me why byte ranges are needed to be used for this at
> all.
>

The question is how much of a hack it is.  What will happen to
existing intermediaries if apparent petty-jiggle-bytes of data start
streaming through them?  Using my crystal ball, I don't see many
serious issues except in pathological cases.  Surely most middleboxes
can already deal, one way or another, with streams getting cut off
before the originally-signalled EOF?  Or with attempting to
pre-allocate too much space for a giant representation?

I like this hack because I can't see it failing too badly if the
resource definitively stop growing before it reaches the Very Large
Number of bytes (certainly not in a way that can't be recovered); and
if it grows beyond that size it's pretty easy to request an Even
Larger Number.

A conservative implementation could even replace the Very Large Number
with a Pretty Big Number, so the overheads of hitting end-of-range and
initiating a new request are made less common.  It's all tuneable.

The *only* change to Range semantics is having the server assume that
an absurdly large range request was intentional, and respond in kind.
And that would only be implemented by servers that are designed to
serve these indeterminate responses in the first place, so it's not a
terrible assumption.

>
> In the case of the appended content, I'm not convinced the argument in the
> introduction isn't a straw man.  2 options are given
>
> 1. Read the whole thing from the beginning.
> 2. multiple byte-range requests.  A latency problem is identified.
>
> 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.

>
> 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
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

Received on Saturday, 17 February 2018 00:46:33 UTC