Re: Out-of-order Frames

I was under no illusions that the frame had any correspondence whatever with HTML, I kind of forgot that element exists. My suggestion is basically that some documents are best represented by Streams of bytes but some of the bytes may take longer to calculate than others. Wouldn't it be great if we could get the easy to calculate (typically static) bytes on the wire as fast as possible and sent the hard to calculate bytes later in the stream. This would let us get the benefits of going to great lengths to break up our applications into multiple documents and build frameworks that can reconstruct them on the client without actually doing any of that work, instead just sending bytes when they are ready.

Sounds like this might be out of scope or too complicated to be in the specification, but I'd at least like to get the group to understand the use case a little better. I guess the base assumption that is being made is that resources are fine grained enough, I challenge that as not what we see in reality — thus things like ESI, etc. Documents are great ways to represent the full information but then you are at the mercy of the document format when you have to turn it into an HTTP stream.

I agree that you can get a lot of the benefit of this if you rearchitect your applications around PUSH_PROMISES but I think you'll find doing something like BigPipe is much easier than implementing abcde below.

Sam

On Jun 22, 2013, at 2:15 PM, David Morris <dwm@xpasc.com> wrote:
> 
> Perhaps I can help with impedence matching here ...
> 
> First, in simple terms, HTTP/2's framing layer provides a mechanism that 
> allows for multiple HTTP requests from the browser to the server on a
> single TCP connection with the response delivered out of order based on
> server decisions, priorities, etc. The word 'frame' in HTTP/2 has no
> semantic correlation with the HTML frame element type. An HTTP/2 frame
> is analgous to a TCP packet. An HTTP request becomes a session within
> the HTTP/2 TCP connection. Frames within a session must be delivered
> in order, but if there are multiple sessions, frames for different
> sessions may be interspersed with each other.
> 
> In your example Sam, I'm not clear if the fill in content is delivered
> under the original request to the server or in response to a element
> in the initial page. In the former, case, there would be strict ordering
> and other tricks needed.
> 
> With HTTP/2.0, what I would envision is:
> a) The browser would request the root html page
> b) The server would deliver this page and though some mechanism (page
>   parsing, application meta data, etc.) identify additional objects
>   need to complete the page.
> c) The sever/application would create PUSH_PROMISE commands for each
>   object that the server thought the browser needed to complete
>   the page rendering. The PROMISE includes request headers that
>   might have been used by the browser to explicitly request the
>   object so the browser can match the PROMISEd object to something
>   it needs to complete the page.
> d) The browser would receive the PROMISEs and probably check to
>   be sure that the promised data wasn't already available in
>   the cache. The browser could decide to reset the promise streams
>   for any reason.
> e) The server would then initiate the promised sessions, each with
>   one of the additional server outputs needed to complete the page.
>   They could be any form of HTTP delivered content.
> 
> This is intended as a conceptual explanation and not a precise
> spec level description.
> 
> Dave Morris
> 
> On Sat, 22 Jun 2013, Sam Pullara wrote:
> 
>> This seems roughly the same as the JavaScript version but now I need even more coordination with the client application. My intent in adding this to the protocol would be that many applications wouldn't even have to know that this optimization is occurring.
>> 
>> Sam
>> 
>> On Jun 22, 2013, at 1:41 PM, William Chan (???) <willchan@chromium.org> wrote:
>> 
>>> Correct me if I'm wrong, but I think what you're saying is the problem is that chunk 2 is not able to be itself delivered as a set of out of order HTML fragments. The current solution as you described allows for chunk 1 to be immediately flushed by the server and then parsed & rendered by the browser, but then we're stuck with waiting for the server-side template expansion to finish completely before flushing chunk 2, rather than letting chunks of the server generated HTML get inserted into the document out of order.
>>> 
>>> I *think* what you actually want to do is something akin to what a dumb mail reader web app might do. In the inbox view, you have a whole bunch of emails. There's no need to fetch the HTML for all those emails and set them in a single innerHTML command. You can fetch all the emails individually, and build subtrees of DOM nodes as they come in, and then insert into the document as needed.
>>> 
>>> In other words, from HTTP land, if you want to be able to fetch different fragments of a single HTTP resource out of order, then maybe it's best to split that HTTP resource into multiple separate HTTP resources. HTTP doesn't care. At the web platform level, use script to re-assemble these different resources together into the actual document. This requires no changes in HTTP nor the web platform.
>>> 
>>> 
>>> On Sat, Jun 22, 2013 at 1:15 PM, Sam Pullara <spullara@gmail.com> wrote:
>>> I'm all for brainstorming. The current solution works basically like this:
>>> 
>>> Chunk 1 (sent immediately):
>>> 
>>> <html>
>>> <body>
>>> <div id="1"></div>
>>> </body>
>>> </html>
>>> 
>>> Chunk 2 (calculated completed and sent later):
>>> <script>document.getElementById("1").innerHTML = "<span>Hi William Chan!</span>";</script>
>>> 
>>> Even if the browser can do no work before receiving all the data it is still better because the bytes are sent sooner than they normally would be sent. However, I think that the browser would be able to parse complete DOM elements in the fragments to do even more work before the page has been completely rendered on the server. The contract with the browser might be that delayed frames must be complete elements like in the example. Rather than out of order frames we might have some way of specifying a named frame to be replaced later. There are a number of possible implementations.
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>> On Jun 22, 2013, at 1:06 PM, William Chan (???) <willchan@chromium.org> wrote:
>>> 
>>>> OK, it sounds like you want to be able to send out of order byte sequences for a single resource, by sending out of order frames for the same HTTP/2 stream. This is not possible without changing HTTP semantics, and HTTP/2 is primarily only working on improving the mapping of HTTP message semantics onto a connection.
>>>> 
>>>> Btw, why would you want to do this? The browser rendering engine cannot do anything with just frame 1 and frame 3 anyway. HTML parsing requires in-order parsing of the document.
>>>> 
>>>> Stepping back, I still don't fully understand the problem with the existing solution that relies on script to dynamically fill in the DOM nodes as they become available. Can you clarify what you are hoping HTTP2 can do that would be better? Maybe there's a better solution here?
>>>> 
>>>> 
>>>> On Sat, Jun 22, 2013 at 12:52 PM, Sam Pullara <spullara@gmail.com> wrote:
>>>> Sorry, let me give a concrete example. You have an HTML page that ultimately needs to look like:
>>>> 
>>>> <html>
>>>> <body>
>>>> <span>Hi William Chan!</span>
>>>> </body>
>>>> </html>
>>>> 
>>>> In order for me to figure out the contents of the span I need to check an authentication database and do some kind of hard computation that might take several 100 ms. What I am proposing is that you could send 3 "frames" or "chunks" or whatever is the final form like this:
>>>> 
>>>> Stream:
>>>> Frame 1:
>>>> <html>
>>>> <body>
>>>> Frame 3:
>>>> </body>
>>>> </html>
>>>> ? some time later ?
>>>> Frame 2:
>>>> <span>Hi William Chan!</span>
>>>> 
>>>> The client then reconstructs the final document, optionally doing some processing on the parts of the document it received before completion. I'm pretty sure the protocol doesn't allow out of order frames within a stream right now. In section 3.4 it states:
>>>> 
>>>>   o  The order in which frames are sent within a stream is significant.
>>>>      Recipients are required to process frames in the order they are
>>>>      received.
>>>> 
>>>> Sam
>>>> 
>>>> On Jun 22, 2013, at 12:47 PM, William Chan (???) <willchan@chromium.org> wrote:
>>>> 
>>>>> I'm having difficulty fully understanding the problem and the proposal. Can you clarify?
>>>>> 
>>>>> * What do you mean by "frame"? Do you mean frames in the HTTP/2 framing layer? Frames in the framing layer can appear in any order (subject to a few rules), so I don't know what out-of-order frames means. Or do you mean like video frames?
>>>>> * If you meant video frames, then if you separate the video into multiple resources, there's no reason the resources can't be sent "out of order", since at the HTTP level there's no concept of order among resources.
>>>>> 
>>>>> 
>>>>> On Sat, Jun 22, 2013 at 12:34 PM, Sam Pullara <spullara@gmail.com> wrote:
>>>>> Commonly in dynamically generated websites there are sections of content that are static and parts that are calculated on a per request basis. The current best practice for accelerating the delivery of a page like this involves leaving identifiable DOM elements where the dynamic content would appear, flushing the entire static page, and then flushing JavaScript script nodes as calculations complete (e.g. Facebook's BigPipe and deferred rendering in mustache.java). This practice only works for HTML pages (with JavaScript enabled) and offers no acceleration for other types of content delivered over HTTP.
>>>>> 
>>>>> One possible solution to this problem would be to allow for out-of-order frames where the static frames are sent as quickly as the connection allows and dynamically generated frames are then sent later as they become available on the server. We would likely not want to enable this in general and would likely need to negotiate this behavior between client and server. Looking at the spec, frames might not be the right place but something on top of frames because of the size limitations.
>>>>> 
>>>>> Has something like this been discussed before? Would this be the right mechanism or are there better ways to do it?
>>>>> 
>>>>> Thanks,
>>>>> Sam
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>

Received on Saturday, 22 June 2013 21:27:50 UTC