Re: Out-of-order Frames

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 19:53:06 UTC