<div class="gmail_quote">On Tue, Jul 6, 2010 at 4:37 PM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson<br>
<<a href="mailto:marques@displague.com">marques@displague.com</a>> wrote:<br>
> The benefit to the user is that they could have less open network<br>
> connections while streaming video from server controlled sites and those<br>
> sites will have the ability to meter their usage more accurately.<br>
> Inserting an extra clip at the end is more of a playlist or scripting<br>
> answer.  Or perhaps a a live re-encoding answer.   I'm looking for a way to<br>
> give the user the raw video file in a metered way.<br>
<br>
</div>It sounds like your use-case is very special, and best handled by<br>
script.  I suggested server-side script -- you could do that today.<br>
Just cut off the HTTP connection when the user has used up their<br>
allotted time.  Alternatively, it might be reasonable to have<br>
client-side scripting for video that's flexible enough to do what you<br>
want.  But a dedicated declarative feature is just not reasonable for<br>
such a specific purpose.</blockquote><div><br></div><div>I tested cutting off the HTTP connection and browsers didn't handle this.  I realize I may need to test a deeper sever than a php exit() can provide.  I have essentially tested this (but not this exactly - filehandles, sessions, additional code, etc):</div>

<div><?php</div><div>header("HTTP/1.1 206 partial");</div><div>header("Accept-Ranges: bytes");</div><div>header("Content-Range: bytes 0-999999/1000000");</div><div>header("Content-Length: 1000000");  // report 1000k</div>

<div>echo str_repeat(" ", 1000); // return 1k</div><div>exit();</div><div><br></div><div>and found that browsers do not attempt to refetch the data or continue with a 206 for the next block.</div><div><br></div>

<div>Shouldn't something like this be be worked into the protocol or the language instead of having to break the stream at a higher level?</div><div><br></div><div>Consider the existing 4xx errors.   The server can tell the client that the request data was too large (1k? - 413/414) or that a "content-length" is required (411) but not that the range length is required or too large (1gb?).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> A 200 response or<br>
> partial 206 responses that returns less than the full requested range is not<br>
> handled by browsers in a consistent or usable way (for this purpose).  Only<br>
> Chrome will continue to fetch where the previous short 206 response left off<br>
> (request 1-10, server replies 1-5, request 6-10, server replies 6-10).  The<br>
> HTTP spec isn't clear about whether UAs should take this behavior - and so<br>
> they don't.<br>
> Some UAs request video without sending "Range: bytes 0-".  The server has no<br>
> way to negotiate that the UA (a) must use ranges to complete the request or<br>
> that (b) the range requested is too large, retry will a smaller range.<br>
<br>
</div>You don't need to return less than the browser requests, until it<br>
actually uses up the bandwidth the user has paid for.  Let the browser<br>
fetch as much of the video as the user wants to view, using<br>
preload=metadata when that's supported by all browsers.  Every time<br>
the server sends a new chunk of video to the user, it should deduct<br>
that much from the user's current balance.  When the user has received<br>
as much video as he's paid for, just have the script exit without<br>
sending more output.<br></blockquote><div><br></div><div>prefetch="metadata" is the plan - but how far forward will the browser attempt to buffer? When will the browser stop buffering and start playing? I think the server/service/html/http side of things should have some say.  I wouldn't want to see browser X seek 10 seconds ahead while browser Y fetches 60 seconds in advance.   </div>

<div><br></div><div>I think buffer="" is a reasonable attribute.  buffer="" being akin to minbuffer="" I feel that a maxbuffer="" is also reasonable.  Again - this would be easier than getting HTTP spec changes made.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
You don't have to return a proper Range header and expect the browser<br>
to issue new requests.  Just pretend you're serving the whole<br>
resource, then cut it off unexpectedly before you've actually returned<br>
all the content.  The browser will handle this fine, it will just<br>
treat it as a network error.  A client-side script can then detect the<br>
error and present nice UI.</blockquote><div><br></div><div>As I stated before - this didn't pan out for me - I will happily test other methods.</div><div><br></div><div>Thanks.</div></div>