- From: Thomas Peterson <hidinginthebbc@gmail.com>
- Date: Wed, 21 Mar 2018 14:09:36 +0000
- To: ietf-http-wg@w3.org
Thank you for your response.
My failure considerations are not around a server failing to acquire live
content, but the scenario when the server itself fails, resulting in the
connection to the client to close and the client may reconnect. In this scenario
(which can be complicated further by having n servers fronted by a load
balancer, which each server reporting different byte ranges for the same asset)
it's not clear to me from the document what a client may do, however as you put
it this may be too format specific to introduce into the specification. Perhaps
there is benefit to including something like:
"A client that may have been disconnected and wishing to continue to receive
only newly-aggregated portions SHOULD perform a HEAD request to learn of any
potential changes in the range available before making a subsequent GET".
I hope that clears the point I'm trying to make.
Regards
On Wed, Mar 21, 2018 at 12:37:29AM -0700, Craig Pratt wrote:
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
> </head>
> <body text="#000000" bgcolor="#FFFFFF">
> <div class="moz-cite-prefix">Thanks Thomas for the
> suggestion/questions. <br>
> <br>
> My thoughts in-line...<br>
> <br>
> cp<br>
> <br>
> On 3/20/18 7:12 AM, Thomas Peterson wrote:<br>
> </div>
> <blockquote type="cite"
> cite="mid:20180320141231.GB11174@raspberrypi">
> <pre wrap="">A question I have with this draft is the behaviour or expectations that may or
> may not occur during failure modes, particularly when a "reset" or roll-over
> happens on the server side. Consider the scenario when the server byte-offset is
> effective reset, and thus it's "range" has shifted beyond the client's
> expectations.</pre>
> </blockquote>
> When a server encounters an error acquiring the live content it's
> incorporating into the representation (e.g. a discontinuity) there
> are a couple options that come to mind: (1) stop appending the
> content into the representation (and optionally start a new one), or
> (2) append the content in a content-type-specific way that the
> client can digest/comprehend.<br>
> <br>
> Either way, the client wouldn't receive a non-success HTTP status
> code when transferring content on each side of the discontinuity. In
> the case of (1), the content would just no longer grow (effectively
> becoming a static representation). For (2) the only effect would be
> a momentary decrease in the transmitted bitrate during the period of
> discontinuity. (you could see this effect periodically in the
> results I presented at IETF 100) To the client, it looks like one
> contiguous sequence of data.<br>
> <br>
> So at this point, you might be thinking "this explanation on
> discontinuities is what should be in the draft RFC". I don think it
> would be great if there was more guidance on live content. The issue
> there is that (a) dealing with discontinuities is fairly
> format-specific, (b) the guidance applies to non-random access cases
> equally, and (c) I'm not sure it has to do with with the "transfer"
> aspect of HTTP - since my argument above is that the server-side
> failure modes really affect the *constitution/construction* of the
> representation and not the *transfer* of it. (as I still consider
> myself a newb in the httpbis group, maybe someone can clarify my
> understanding) <br>
> <br>
> If only (a) and (b) apply, there might be a case to be made for a
> format-agnostic "Live Content and Errors/Discontinuities" draft RFC.
> But my thinking has been that it's a bit too far out of scope for
> this draft. <br>
> <br>
> <blockquote type="cite"
> cite="mid:20180320141231.GB11174@raspberrypi">
> <pre wrap="">I don't see any reference in this draft that explicitly call out when 416
> responses should be sent. Should these things be called out?
>
> Regards</pre>
> </blockquote>
> <br>
> I think this statement from RFC-7233 (section 4.4) describes the 416
> cases pretty well: <br>
> <blockquote><tt>The 416 (Range Not Satisfiable) status code
> indicates that none of</tt><br>
> <tt>the ranges in the request’s Range header field (Section 3.1)
> overlap</tt><br>
> <tt>the current extent of the selected resource</tt><br>
> </blockquote>
> Unfortunately, section 4.4 trips over itself a bit when it tries to
> talk about byte-range-specific simplifications. But I don't think
> it's appropriate to clarify this in our draft. (Perhaps this can be
> cleaned up as part of HTTPter?)<br>
> <br>
> And while it might be useful to provide examples in the draft, I've
> tried to provide examples of ways to interact with a
> live/aggregating server that should *avoid* 416 errors (and get 206
> instead). But the cool thing about the way that 7233 is written is
> that a client can really respond to a 206 and 416 similarly - since
> they both include a Content-Range response header.<br>
> <br>
> Anyway, hope this helps. And please let me know if I'm missing
> something (like the point of your question)...<br>
> <blockquote type="cite"
> cite="mid:20180320141231.GB11174@raspberrypi">
> <pre wrap="">
>
> On Tue, Mar 20, 2018 at 05:19:38AM -0700, <a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a> wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Hypertext Transfer Protocol WG of the IETF.
>
> Title : HTTP Random Access and Live Content
> Authors : Craig Pratt
> Darshak Thakore
> Barbara Stark
> Filename : draft-ietf-httpbis-rand-access-live-03.txt
> Pages : 11
> Date : 2018-03-20
>
> Abstract:
> To accommodate byte range requests for content that has data appended
> over time, this document defines semantics that allow a HTTP client
> and server to perform byte-range GET and HEAD requests that start at
> an arbitrary byte offset within the representation and ends at an
> indeterminate offset.
>
>
> The IETF datatracker status page for this draft is:
> <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/">https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/</a>
>
> There are also htmlized versions available at:
> <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03">https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03</a>
> <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03</a>
>
> A diff from the previous version is available at:
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03">https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03</a>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-drafts/</a>
>
>
> </pre>
> </blockquote>
> <pre wrap="">
> </pre>
> </blockquote>
> <p><br>
> </p>
> <div class="moz-signature">-- <br>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
> <meta http-equiv="Content-Style-Type" content="text/css">
> <title></title>
> <meta name="Generator" content="Cocoa HTML Writer">
> <meta name="CocoaVersion" content="1038.36">
> <style type="text/css">
> p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Lucida Console'}
> p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
> table.t1 {border-collapse: collapse}
> td.td1 {background-color: #bffdba; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
> td.td2 {background-color: #9fd39b; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
> td.td3 {background-color: #78a075; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; border-color: #000000 #000000 #000000 #000000; padding: 0.0px 5.0px 0.0px 5.0px}
> </style>
> <table class="t1" cellspacing="0" cellpadding="0">
> <tbody>
> <tr>
> <td class="td1" valign="middle">
> <p class="p1">craig pratt</p>
> <p class="p1">caspia consulting</p>
> <p class="p1"><a class="moz-txt-link-abbreviated" href="mailto:craig@ecaspia.com">craig@ecaspia.com</a></p>
> <p class="p1">503.706.2933</p>
> </td>
> <td class="td2" valign="middle">
> <p class="p2"><br>
> </p>
> </td>
> <td class="td3" valign="middle">
> <p class="p2"><br>
> </p>
> </td>
> </tr>
> </tbody>
> </table>
> <p class="p2"><br>
> </p>
> </div>
> </body>
> </html>
>
Received on Wednesday, 21 March 2018 14:10:10 UTC