Subject: Out-of-order Frames

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 12:34:35 -0700

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 22 Jun 2013 12:47:24 -0700

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 <[email-masked]> 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
>
>
>

---

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 12:52:40 -0700

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 (陈智昌) <[email-masked]> 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.
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 22 Jun 2013 13:06:25 -0700

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 <[email-masked]> wrote:

> 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:
> 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:
>

---

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 13:15:43 -0700

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 (陈智昌) <[email-masked]> 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?
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 22 Jun 2013 13:41:52 -0700

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 <[email-masked]> wrote:

> 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
>
>
>
> 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?
>
>

---

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 13:47:51 -0700

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 (陈智昌) <[email-masked]> 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.
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 22 Jun 2013 14:11:17 -0700

Sorry, it wasn't clear you wanted this optimization to happen transparently
without application knowledge, I thought you were trying just to achieve a
better optimization of some sort.

At this point, most of the conversation is revolving around how the web
platform uses HTTP in resource loading, and thus the discussion is better
moved to a web platform list, perhaps whatwg or public-webapps, I dunno. If
the feeling is that new HTTP semantics would be useful, we can discuss that
here, but my instinct is that at an HTTP level, it'd be best just to use a
different resource rather than try to allow out of order response bodies.
I'm open to what others on this mailing list think though.

On Sat, Jun 22, 2013 at 1:47 PM, Sam Pullara <[email-masked]> 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
>
>> 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 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
>>> * 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 <[email-masked]>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.
>>>>

---

From: David Morris <[email-masked]>
Date: Sat, 22 Jun 2013 14:15:18 -0700 (PDT)

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:

> On Jun 22, 2013, at 1:41 PM, William Chan (???) <[email-masked]> wrote:
> 
> > On Jun 22, 2013, at 1:06 PM, William Chan (???) <[email-masked]> wrote:
> > 
> >> ? some time later ?
> >> On Jun 22, 2013, at 12:47 PM, William Chan (???) <[email-masked]> wrote:
> >>

---

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 14:19:36 -0700

Why web platform? — that was just an example that works today because Javascript allows us to conspire with the client to fragment and reassemble the document. This could be used just as easily when delivering any type of content where some of the content is known statically and some must be calculated. For example, you might want to have a JSON object where parts of the object are known at different times while processing on the server. I think this comes up with virtually any document you could imagine serving (I can think of interesting cases for image formats, XML, JSON, etc). I'd like to avoid mangling the data format just to get the bytes on the wire as soon as possible, especially since many document formats have long been set in stone and cleverly implementing this would get a benefit as long as the system serving them and the protocol stack receiving them could conspire to fragment and reconstruct the document.

Sam

On Jun 22, 2013, at 2:11 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Sorry, it wasn't clear you wanted this optimization to happen transparently without application knowledge, I thought you were trying just to achieve a better optimization of some sort.
> 
> At this point, most of the conversation is revolving around how the web platform uses HTTP in resource loading, and thus the discussion is better moved to a web platform list, perhaps whatwg or public-webapps, I dunno. If the feeling is that new HTTP semantics would be useful, we can discuss that here, but my instinct is that at an HTTP level, it'd be best just to use a different resource rather than try to allow out of order response bodies. I'm open to what others on this mailing list think though.
> 
>

---

From: Sam Pullara <[email-masked]>
Date: Sat, 22 Jun 2013 14:27:28 -0700

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Jun 2013 14:30:55 -0700

FWIW -

Sam is pointing out that all bytes in a response aren't equal, in terms of what it takes to generate them. Some are very easy (e.g., static parts of templates), whereas others take time / cpu / etc. (e.g., database calls, service calls, getting something off of disk).

A smart app could send the "easy" bytes immediately, to use the available bandwidth, while the "hard" ones churned away in the background.

Yes, the browser would have to buffer the response, but this would utilise the connection more optimally in some cases.

I think the question is whether this is a useful enough thing to put into the core spec (vs. an extension), and whether it's a DDoS vector.

As a server-side person, I'd be VERY interested in this (especially combined with some aggregation frameworks like ESI). Again, FWIW.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Jun 2013 14:41:31 -0700

I agree that what Mark describes is interesting, I'm just not sure it's
something we should consider at this point. There are many ways that kind
of mechanism could become a very deep rabbit hole.
On Jun 22, 2013 2:32 PM, "Mark Nottingham" <[email-masked]> wrote:

> FWIW -
>
> Sam is pointing out that all bytes in a response aren't equal, in terms of
> what it takes to generate them. Some are very easy (e.g., static parts of
> templates), whereas others take time / cpu / etc. (e.g., database calls,
> service calls, getting something off of disk).
>
> A smart app could send the "easy" bytes immediately, to use the available
> bandwidth, while the "hard" ones churned away in the background.
>
> Yes, the browser would have to buffer the response, but this would utilise
> the connection more optimally in some cases.
>
> I think the question is whether this is a useful enough thing to put into
> the core spec (vs. an extension), and whether it's a DDoS vector.
>
> As a server-side person, I'd be VERY interested in this (especially
> combined with some aggregation frameworks like ESI). Again, FWIW.
>
> Cheers,
>
>
> > Sorry, it wasn't clear you wanted this optimization to happen
> transparently without application knowledge, I thought you were trying just
> to achieve a better optimization of some sort.
> >
> > 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
> >
> >> 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
> >> 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.
> >>
> >>
> >>> 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.
> >>>
> >>>> * 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?
> >>>> Has something like this been discussed before? Would this be the
> right mechanism or are there better ways to do it?
> >>>>
> >>>> Thanks,
> >>>> Sam
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
> --

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 22 Jun 2013 15:12:44 -0700

> service calls, getting something off of disk).

Yes yes, this is all well understood.

> the connection more optimally in some cases.

OK, I think this is the important thing. Servers could utilize a new
out-of-order write API to do this, and clients would not necessarily have
to switch to a new out of order read API if their HTTP stack just buffered.
So from that perspective, this could be transparent to a client web app,
but not to the server nor the client (both which need to change their HTTP
stacks to understand this and buffer) nor a servlet (which would have to
leverage the server's out of order write API). If this happened, then you
might be able to utilize the connection more optimally in some cases. You
wouldn't want to just always do this in the web platform case, because
that'd very likely hurt performance in a large number of cases. And the
existing solution is better because the rendering engine gets to process
more of the bytes sooner, but as noted, that requires work on the web devs'
behalf.

Sorry for misunderstanding earlier, it was not evident to me exactly what
was being addressed. I agree that this is something we can discuss here.

---

From: Zhong Yu <[email-masked]>
Date: Sat, 22 Jun 2013 20:45:51 -0500

this reminds me another request for out-of-order delivery of an http entity

http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0259.html

(it would be funny though to implement out-of-order frams on top of
TCP which already deals with out-of-order segments)

Zhong Yu

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 23 Jun 2013 14:00:46 +1200

On 23/06/2013 8:15 a.m., Sam Pullara wrote:
> 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.

I completely agree. This current style of coding which relies completely 
on JavaScript execution is rather nasty.

When I learned HTML there were these things called OBJECT tags which we 
were taught to use for this exact use-case...

example.html would look like this:
<html><body>
<object type="text/html" data="/name.cgi">Guest - Please <button 
name="login" onclick="/login.cgi">Log In</button></object>
</body></html>

name.cgi would produce this part:
<div>Hi Sam,</div>

and login.cgi would do anything required to perform login before either 
returning.

The UX used to be seamless, work on all the HTML3 or HTML4 compliant 
browsers and the page rendering time was at least twice as fast as it is 
when waiting for JS engines to load, parse, execute *then* do the extra 
downloads. The above still works today, although in HTML5 the things 
seem to have taken a u-turn towards complexity with IFRAME replacing the 
earlier nested OBJECT.

IMHO, your requested protocol change is not necessary - it is just 
another complication of the protocol to resolve a disagreement at the 
markup and resource format (webapp?) layer. Which seems to already have 
a host of useful solutions. Not all resources are equal in which 
solution they can use any more than they are equal in resource 
consumption to output.

Amos

>
> Sam
>
>
>
>
> On Jun 22, 2013, at 1:06 PM, William Chan (陈智昌) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> 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.
>>
>> 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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     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:
>>     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:
>>
>>     On Jun 22, 2013, at 12:47 PM, William Chan (陈智昌)
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>     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?
>>>     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
>>>     <[email-masked] <mailto:[email-masked]>> 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.
>>>
>>>         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
>>>
>>>
>>>
>>
>>
>

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 23 Jun 2013 14:18:27 +1200

> TCP which already deals with out-of-order segments)

It does sound very similar. But the kfall draft is very close to 
technically possible.

The case as presented by Sam the "chunk 3" starting offset is completely 
unknown to both client *and* server. Take an arbitrary length string, 
insert a second arbitrary string (length M) into it at a pre-known 
starting offset (N) and somehow determine the value of N+M before M 
comes into existence. Not possible until we fix our machines phychic 
abilities.

This is a solved problem in markup languages, they use a special tag 
(OBJECT and IFRAME I referred to earlier, IMG, SCRIPT, VIDEO are others 
in HTML) in a tree structure which can be adjusted - you should all 
recognise the DOM. However outside of markup languages multimedia 
resources are not able to split their content over a tree-like structure 
without becoming something else.

Amos

>
> Zhong Yu
>
>
> On Sat, Jun 22, 2013 at 2:34 PM, Sam Pullara wrote:

---

From: Sam Pullara <[email-masked]>
Date: Sun, 23 Jun 2013 09:25:09 -0700

The OBJECT, IFRAME and similar solutions don't work because they aren't in the same document.

Sam

On Jun 22, 2013, at 7:18 PM, Amos Jeffries <[email-masked]> wrote:

> It does sound very similar. But the kfall draft is very close to technically possible.
> 
> The case as presented by Sam the "chunk 3" starting offset is completely unknown to both client *and* server. Take an arbitrary length string, insert a second arbitrary string (length M) into it at a pre-known starting offset (N) and somehow determine the value of N+M before M comes into existence. Not possible until we fix our machines phychic abilities.
> 
> This is a solved problem in markup languages, they use a special tag (OBJECT and IFRAME I referred to earlier, IMG, SCRIPT, VIDEO are others in HTML) in a tree structure which can be adjusted - you should all recognise the DOM. However outside of markup languages multimedia resources are not able to split their content over a tree-like structure without becoming something else.
> 
> Amos
> 
>> 
>> Zhong Yu
>> 
>>

---

From: Mike Belshe <[email-masked]>
Date: Sun, 23 Jun 2013 15:53:05 -0700

It seems to me that a combination of client-side templates and server push
could do this with HTTP/2.

The client side template is effectively the placeholder you speak of.  The
slow-to-compute server resources would be server push streams.  Javascript
would glue them together such that receipt of the server push would put the
content in place.

One thing we haven't defined (and maybe this is where WHATWG could help) is
with Javascript APIs for server push.  For instance, what if the server can
push a resource that the client never requests?  Some simple javascript
event notifications could really be interesting here.

Mike

On Sun, Jun 23, 2013 at 9:25 AM, Sam Pullara <[email-masked]> wrote:

> insert a second arbitrary string (length M) into it at a pre-known starting
> offset (N) and somehow determine the value of N+M before M comes into
> existence. Not possible until we fix our machines phychic abilities.
> >
> (OBJECT and IFRAME I referred to earlier, IMG, SCRIPT, VIDEO are others in
> HTML) in a tree structure which can be adjusted - you should all recognise
> the DOM. However outside of markup languages multimedia resources are not
> able to split their content over a tree-like structure without becoming
> something else.
> >
> > Amos
> >
> >>
> >> Zhong Yu
> >>
> >>

---

From: Sam Pullara <[email-masked]>
Date: Sun, 23 Jun 2013 16:20:06 -0700

This model is pretty easy to do as described without any additional changes to the spec.  I'd like the protocol to support it so it would work with any document format and no application support. Sam   

---Sent from Boxer | http://getboxer.com

On Sun, Jun 23, 2013 at 03:53 PM, Mike Belshe  wrote:It seems to me that a combination of client-side templates and server push could do this with HTTP/2. The client side template is effectively the placeholder you speak of.  The slow-to-compute server resources would be server push streams.  Javascript would glue them together such that receipt of the server push would put the content in place.   One thing we haven't defined (and maybe this is where WHATWG could help) is with Javascript APIs for server push.  For instance, what if the server can push a resource that the client never requests?  Some simple javascript event notifications could really be interesting here.   Mike     On Sun, Jun 23, 2013 at 9:25 AM, Sam Pullara <[email-masked]> wrote:The OBJECT, IFRAME and similar solutions don't work because they aren't in the same document.  Sam   On Jun 22, 2013, at 7:18 PM, Amos Jeffries <[email-masked]> wrote:  > On 23/06/2013 1:45 p.m., Zhong Yu wrote: >> this reminds me another request for out-of-order delivery of an http entity >> >> http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0259.html >> >> (it would be funny though to implement out-of-order frams on top of >> TCP which already deals with out-of-order segments) > > It does sound very similar. But the kfall draft is very close to technically possible. > > The case as presented by Sam the "chunk 3" starting offset is completely unknown to both client *and* server. Take an arbitrary length string, insert a second arbitrary string (length M) into it at a pre-known starting offset (N) and somehow determine the value of N+M before M comes into existence. Not possible until we fix our machines phychic abilities. > > This is a solved problem in markup languages, they use a special tag (OBJECT and IFRAME I referred to earlier, IMG, SCRIPT, VIDEO are others in HTML) in a tree structure which can be adjusted - you should all recognise the DOM. However outside of markup languages multimedia resources are not able to split their content over a tree-like structure without becoming something else. > > Amos > >> >> Zhong Yu >> >> >> On Sat, Jun 22, 2013 at 2:34 PM, Sam Pullara 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 >>> >>> > >

---

From: Ilya Grigorik <[email-masked]>
Date: Sun, 23 Jun 2013 16:39:11 -0700

On Sun, Jun 23, 2013 at 3:53 PM, Mike Belshe <[email-masked]> wrote:

> One thing we haven't defined (and maybe this is where WHATWG could help)
> is with Javascript APIs for server push.  For instance, what if the server
> can push a resource that the client never requests?  Some simple javascript

Yep, I think this is well above this group.. WHATWG is the right place to
tackle this.

FWIW, you can "simulate" these types of notifications today by combining
SSE with server-push:
http://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/ (see
client notifications section)

ig

---

From: Michael Sweet <[email-masked]>
Date: Mon, 24 Jun 2013 07:57:48 -0400

+1 on not complicating HTTP/2.0 with supporting out-of-order fragments.

(I don't buy the transparent-to-application argument - that level of optimization will require coordination and is probably better suited to a framework that serves up the different resources rather than generating out-of-order HTML fragments...)

>>>> Has something like this been discussed before? Would this be the right mechanism or are there better ways to do it?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Roberto Peon <[email-masked]>
Date: Mon, 24 Jun 2013 14:35:51 -0700

For anything to be interpreted properly, the receiving side must know what
it is.
HTTP/2's framing layer supports arbitrary numbers of combinations of
'stuff' and metadata to identify what they are.

As has been said earlier (Mike is dead-on) what is missing is an API which
describes how to use this kind of functionality, so ++ what Mike said.
-=R

On Mon, Jun 24, 2013 at 4:57 AM, Michael Sweet <[email-masked]> wrote:

> (I don't buy the transparent-to-application argument - that level of
> optimization will require coordination and is probably better suited to a
> framework that serves up the different resources rather than generating
> out-of-order HTML fragments...)
>
>
>>> On Sat, Jun 22, 2013 at 12:52 PM, Sam Pullara <[email-masked]>wrote:
>>>