Subject: Some thoughts on server push and client pull

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 7 Jun 2012 01:30:47 +0000

Hi folks,

Amongst some collegues, we've been thinking about server push in HTTP 2.0 and have some ideas we'd like to share as a way to promote discussion on this subject

1. Overview
Server Push is an interesting idea that could provide some performance gains for HTTP 2.0 clients, however we don't believe it is core the HTTP 2.0 protocol. Server Push could result in servers sending unnecessary data to the client, introduces potential delays to avoid race conditions and is mostly relevant for browser applications. A less complex alternative that addresses some of these drawbacks while better aligning with legacy HTTP, "Smart Client Pull", is proposed below.

2. Issues with current Server Push in SPDY

We don't envision Server push as part of the base HTTP 2.0 protocol, but see it as a potentially interesting extension, as long as there is some way for the client to exert some control over when and how it is used. One fundamental requirement is for clients to be able to control "Server Push" behavior via a new opt-in <name TBD> header.  Servers MUST NOT push unrequested data to the client, unless the top level page request <name TBD> header is set to allow "Server Push".

Server Push does not require any validation prior to pushing data to the client, which could result in the server sending unnecessary data to clients that have some of the pushed resources stored in their cache.

Furthermore, "Server Push" introduces a race condition in which a client could start a new request for data that the server is in the process of pushing, effectively causing the same resource to be downloaded twice. SPDY addresses the race condition by not sending any data (headers are OK) for the top level page, until all of the SYN_STREAM for the dependencies it will push are sent:

"To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content which could allow the client to discover the pushed resource and request it."

We agree that SPDY's proposal is a good way to mitigate the race condition in Server Push without introducing significant complexity. Unfortunately mitigating the race condition in this manner prevents the server from sending data for the top level page. This could result in user-visible delays.  Whether or not the user will see a delay will depend on what messages (how many and how large) the server is pushing to the client.

3. Smart Client Pull alternative to Server Push

We would like to propose an alternative to Server Push for discussion. This alternative is closely aligned with existing standards and could even work for HTTP 1.1.

When a server receives an HTTP request for a top level page, the server will generate a list of resources needed to fully load the top level page. The server will send the optimal pre-fetch list to the client, via LINK headers, with a "prefetch" link relation type (defined in HTML5 per http://www.iana.org/assignments/link-relations/link-relations.xml).
The server SHOULD also include the corresponding cache validators for each resource in the pre-fetch list. An extension to the "prefetch" link relation type will be needed to allow cache validator data.

When a client receives data for a top level page, it will begin processing the top level page response, while simultaneously pre-fetching resources in the pre-fetch list that are not in the client cache or that are cached but invalid, as indicated by the cache validators included in the pre-fetch list. Servers SHOULD only include resources that block loading of the top level page in the optimal pre-fetch list.

This eliminates the need to block data for the top level request until all SYN_STREAM for pushed dependencies are sent, in order to avoid the race condition. The client would pre-fetch the resources in the optimal pre-fetch list, which introduces an extra RTT.  We should gather data to determine how much more significant this RTT is, when compared to the complexity of implementing server push and some of the benefits obtained by multiplexing new connections for the dependency resources.

Clients will control "Smart Client Pull" behavior via a new opt-in <name TBD> header. Servers MUST NOT push LINK header and associated cache validator data to clients, unless the top level page request <name TBD> header is set to allow "Smart Client Pull".

4. Other alternatives

These are other client-driven alternatives to "Server Push". However we need to capture additional data to determine the impact and cost of each:

a.            Bundling of HTTP resources: Administrators can package static server side resources needed to download a webpage as a single entity. A client would download all static dependencies by issuing a single HTTP request. However, this could result in the client receiving data which it already had in its cache.

b.            Combination of Smart Client Pull and Bundling of HTTP resources (a).

5.            Recommendation:

"Server Push" should not be a part of the core HTTP2.0 spec for the following reasons:

- "Server Push" is not core to defining the HTTP 2.0 transport.

- "Server Push" without optimizations can result in unnecessary data being sent to the client.

- "Server Push" even with optimizations, introduces delays to avoid race conditions that are not present in other solutions.

- "Server Push" is relevant primarily for browser applications and not for more general use cases.

6.            Areas for further discussion:

- How to send the "prefetch" list and its corresponding cache-validators in an efficient manner. These resources are URLs, which can be really long, causing us to transmit a additional data when using Smart Client Pull.

- Validation of cached resources included in the prefetch list will require additional CPU cycles.  However, it is no different from cache validation currently performed on cache resources. The tradeoff here is CPU load in order to avoid unnecessary download of resources already in the client's cache.

- Compare "Smart Server Hints" and "Bundling" to determine the impact of the features in isolation and combined.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 6 Jun 2012 18:47:38 -0700

I agree.

Perhaps another reason for dropping push at this point may be that I don't
know of any efforts to seriously deploy it.  If no implementors are willing
to speak up that they plan to use it, deploy it, measure it, and report
results on their findings, then it is a good time to drop it altogether and
focus on the other parts of the protocol instead.

Mike

On Wed, Jun 6, 2012 at 6:30 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  Hi folks,****
>
> ** **
>
> Amongst some collegues, we've been thinking about server push in HTTP 2.0
> and have some ideas we'd like to share as a way to promote discussion on
> this subject****
>
> ** **
>
> 1. Overview****
>
> Server Push is an interesting idea that could provide some performance
> gains for HTTP 2.0 clients, however we don’t believe it is core the HTTP
> 2.0 protocol. Server Push could result in servers sending unnecessary data
> to the client, introduces potential delays to avoid race conditions and is
> mostly relevant for browser applications. A less complex alternative that
> addresses some of these drawbacks while better aligning with legacy HTTP,
> “Smart Client Pull”, is proposed below. ****
>
> ** **
>
> ** **
>
> 2. Issues with current Server Push in SPDY****
>
> ** **
>
> We don't envision Server push as part of the base HTTP 2.0 protocol, but
> see it as a potentially interesting extension, as long as there is some way
> for the client to exert some control over when and how it is used. One
> fundamental requirement is for clients to be able to control “Server Push”
> behavior via a new opt-in <name TBD> header.  Servers MUST NOT push
> unrequested data to the client, unless the top level page request <name
> TBD> header is set to allow “Server Push”.****
>
> ** **
>
> Server Push does not require any validation prior to pushing data to the
> client, which could result in the server sending unnecessary data to
> clients that have some of the pushed resources stored in their cache.****
>
> ** **
>
> Furthermore, "Server Push" introduces a race condition in which a client
> could start a new request for data that the server is in the process of
> pushing, effectively causing the same resource to be downloaded twice. SPDY
> addresses the race condition by not sending any data (headers are OK) for
> the top level page, until all of the SYN_STREAM for the dependencies it
> will push are sent:****
>
> ** **
>
> "To minimize race conditions with the client, the SYN_STREAM for the
> pushed resources MUST be sent prior to sending any content which could
> allow the client to discover the pushed resource and request it."****
>
> ** **
>
> We agree that SPDY's proposal is a good way to mitigate the race condition
> in Server Push without introducing significant complexity. Unfortunately
> mitigating the race condition in this manner prevents the server from
> sending data for the top level page. This could result in user-visible
> delays.  Whether or not the user will see a delay will depend on what
> messages (how many and how large) the server is pushing to the client.****
>
> ** **
>
> 3. Smart Client Pull alternative to Server Push****
>
> ** **
>
> We would like to propose an alternative to Server Push for discussion.
> This alternative is closely aligned with existing standards and could even
> work for HTTP 1.1.****
>
> ** **
>
> When a server receives an HTTP request for a top level page, the server
> will generate a list of resources needed to fully load the top level page.
> The server will send the optimal pre-fetch list to the client, via LINK
> headers, with a "prefetch" link relation type (defined in HTML5 per
> http://www.iana.org/assignments/link-relations/link-relations.xml). ****
>
> ****
>
> The server SHOULD also include the corresponding cache validators for each
> resource in the pre-fetch list. An extension to the “prefetch” link
> relation type will be needed to allow cache validator data.****
>
> ** **
>
> When a client receives data for a top level page, it will begin processing
> the top level page response, while simultaneously pre-fetching resources in
> the pre-fetch list that are not in the client cache or that are cached but
> invalid, as indicated by the cache validators included in the pre-fetch
> list. Servers SHOULD only include resources that block loading of the top
> level page in the optimal pre-fetch list.****
>
> ** **
>
> This eliminates the need to block data for the top level request until all
> SYN_STREAM for pushed dependencies are sent, in order to avoid the race
> condition. The client would pre-fetch the resources in the optimal
> pre-fetch list, which introduces an extra RTT.  We should gather data to
> determine how much more significant this RTT is, when compared to the
> complexity of implementing server push and some of the benefits obtained by
> multiplexing new connections for the dependency resources.****
>
> ** **
>
> Clients will control “Smart Client Pull” behavior via a new opt-in <name
> TBD> header. Servers MUST NOT push LINK header and associated cache
> validator data to clients, unless the top level page request <name TBD>
> header is set to allow “Smart Client Pull”. ****
>
> ** **
>
> 4. Other alternatives ****
>
> ** **
>
> These are other client-driven alternatives to “Server Push”. However we
> need to capture additional data to determine the impact and cost of each:*
> ***
>
> ** **
>
> a.            Bundling of HTTP resources: Administrators can package
> static server side resources needed to download a webpage as a single
> entity. A client would download all static dependencies by issuing a single
> HTTP request. However, this could result in the client receiving data which
> it already had in its cache.****
>
> ** **
>
> b.            Combination of Smart Client Pull and Bundling of HTTP
> resources (a).****
>
> ** **
>
> 5.            Recommendation:****
>
> ** **
>
> “Server Push” should not be a part of the core HTTP2.0 spec for the
> following reasons:****
>
> ** **
>
> - “Server Push” is not core to defining the HTTP 2.0 transport.****
>
> ** **
>
> - “Server Push” without optimizations can result in unnecessary data being
> sent to the client.****
>
> ** **
>
> - “Server Push” even with optimizations, introduces delays to avoid race
> conditions that are not present in other solutions.****
>
> ** **
>
> - “Server Push” is relevant primarily for browser applications and not for
> more general use cases.****
>
> ** **
>
> 6.            Areas for further discussion: ****
>
> ** **
>
> - How to send the “prefetch" list and its corresponding cache-validators
> in an efficient manner. These resources are URLs, which can be really long,
> causing us to transmit a additional data when using Smart Client Pull.****
>
> ** **
>
> - Validation of cached resources included in the prefetch list will
> require additional CPU cycles.  However, it is no different from cache
> validation currently performed on cache resources. The tradeoff here is CPU
> load in order to avoid unnecessary download of resources already in the
> client’s cache.****
>
> ** **
>
> - Compare “Smart Server Hints” and “Bundling” to determine the impact of
> the features in isolation and combined.****
>

---

From: Alek Storm <[email-masked]>
Date: Wed, 6 Jun 2012 21:29:22 -0500

On Wed, Jun 6, 2012 at 8:30 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  <snip>
> TBD> header is set to allow “Server Push”.
>

I have not verified this, but I believe the client can achieve the same
effect in SPDYv3 by sending a GOAWAY frame, indicating that the other
endpoint must not open any new streams.

> clients that have some of the pushed resources stored in their cache.
>

I proposed a detailed system of cache control for pushed resources on the
spdy-dev mailing list, before I knew of the existence of this list. I plan
to post it here soon.

**
>
> **Furthermore, "Server Push" introduces a race condition in which a
> client could start a new request for data that the server is in the process
> of pushing, effectively causing the same resource to be downloaded twice.
> SPDY addresses the race condition by not sending any data (headers are OK)
> for the top level page, until all of the SYN_STREAM for the dependencies it
> will push are sent:
>
> **
>
> ** **
>
> messages (how many and how large) the server is pushing to the client.
>

Pushed content is likely to be that which is required to be present at page
load in the first place. Pushed CSS stylesheets would prevent flashes of
unstyled content (FOUC), and pushed scripts that trigger on page load would
be able to execute before the user is able to interact with the page.

> level page in the optimal pre-fetch list.
>

Mozilla (and Chrome, I believe) already interpret rel=prefetch as
indicating resources that are likely to be useful in *future* page loads,
not necessarily the current one - I would recommend avoiding the naming
conflict. SPDY appears to have an ancillary proposal for a rel=subresource
with essentially the semantics you describe, at
http://dev.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource,
which I believe is already implemented in Chrome.

My soon-to-come cache control proposal will obviate the need for extensions
to the Link header, and would afford more fine-grained control.

Alek

---

From: Alek Storm <[email-masked]>
Date: Wed, 6 Jun 2012 21:34:14 -0500

> focus on the other parts of the protocol instead.

I recently released a fork of Tornado (http://www.tornadoweb.org/)
implementing SPDY support with server push - we're certainly serious about
it :). As it's only a few days old, I don't know of anyone who's deployed
it yet and has results to report, but I will ask around.

Alek

Mike
>> We agree that SPDY's proposal is a good way to mitigate the race
>> condition in Server Push without introducing significant complexity.
>> Unfortunately mitigating the race condition in this manner prevents the
>> server from sending data for the top level page. This could result in
>> user-visible delays.  Whether or not the user will see a delay will depend
>> on what messages (how many and how large) the server is pushing to the
>> client.****
>>
>> ** **
>>
>> The server SHOULD also include the corresponding cache validators for
>> each resource in the pre-fetch list. An extension to the “prefetch” link
>> When a client receives data for a top level page, it will begin
>> processing the top level page response, while simultaneously pre-fetching
>> resources in the pre-fetch list that are not in the client cache or that
>> are cached but invalid, as indicated by the cache validators included in
>> the pre-fetch list. Servers SHOULD only include resources that block
>> loading of the top level page in the optimal pre-fetch list.****
>>
>> ** **
>>
>> This eliminates the need to block data for the top level request until
>> all SYN_STREAM for pushed dependencies are sent, in order to avoid the race
>> need to capture additional data to determine the impact and cost of each:
>> ****
>>
>> ** **
>>
>> - “Server Push” without optimizations can result in unnecessary data
>> being sent to the client.****
>>
>> ** **
>>
>> - “Server Push” is relevant primarily for browser applications and not
>> for more general use cases.****
>>
>> ** **
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 7 Jun 2012 09:43:33 -0700

* Google is working on efforts to seriously deploy SPDY server push on our
properties. I can't comment further on timeline, but I hope to provide data
to guide our discussions, so let's not axe it just yet.
* To my knowledge, Amazon is using it in their Silk browser. A proxy that
uses server push is a fascinating use case, and it'd be cool to get data on
that first.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Jun 2012 09:54:28 -0700

> uses server push is a fascinating use case, and it'd be cool to get data on

I'm with Mike and Gabriel on this one.

It would be nice if HTTP/2.0 discussions could be scoped to exclude
discussions on new protocol semantics.  If you feel especially
attached to the idea of push, then my preference would be to see a new
draft on it.

--Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 10:56:39 -0600

> attached to the idea of push, then my preference would be to see a new

+1

/psa

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 7 Jun 2012 10:07:28 -0700

> attached to the idea of push, then my preference would be to see a new

Can you clarify what you mean by new protocol semantics? Does multiplexing
count as a new protocol semantic? What's your proposed scope?

I understand the desire to split out server push into a separate draft /
extension. If we don't have data to support push, then by all means we
should drop it. The main concern I have is with regards to treating push as
an optional feature / extension. As many of us have stated repeatedly on
this mailing list, many things that are optional simply become unusable in
real, public deployments.

---

From: Rajeev Bector <[email-masked]>
Date: Thu, 7 Jun 2012 12:12:52 -0500

Hi

I am Rajeev and I am leading the SPDY investigation @Yahoo (our 
investigations have begun fairly recently so I am still catching up and 
wrapping my head around all things SPDY). Hey - but I have opinions 
already :-).

After my initial analysis of the state of things, I am inclined towards 
William's proposal (as in we should look at alternative ways to 
"flatten" content of main pages and explore other client driven 
approaches and possibly include this as optional extension). For one, 
this keep things simpler by following the client-drives-it-all paradigm.

Push introduces a completely new communication paradigm which needs to 
be thought about in more detail from various points of view (including 
the cost/benefit/complexity trade-offs). Several of the points mentioned 
in this thread (and others on spdy-dev@) seem to be important and seem 
to be a relative state of immaturity to be ready for an HTTP 2.0 level 
proposal (as opposed to many other parts of the SPDY proposal on which 
more detailed thinking seems to have been done).

Question : the claims of upto 60% improvement in latency with SPDY (vs 
plain HTTP) - did those include server push or not ? My guess is not.

Cheers,
Rajeev

On 6/7/12 11:56 AM, Peter Saint-Andre wrote:
>> On 7 June 2012 09:43, William Chan (陈智昌)<[email-masked]>  wrote:

---

From: Patrick McManus <[email-masked]>
Date: Thu, 07 Jun 2012 13:19:04 -0400

On Thu, 2012-06-07 at 10:07 -0700, William Chan (陈智昌) wrote:

> 
> I understand the desire to split out server push into a separate
> draft / extension. If we don't have data to support push, then by all
> means we should drop it.

imo it doesn't need to be proven out at the early ID stage. Its totally
fair to take an idea like Push and get some experience with it - and
doing that in the open in a inter-vendor way is better experience (and
that realistically needs an ID). If it harms the implementation rate,
that's a data point right there :)

I'm pessimistic about push mostly because I don't think the upside is
very impressive for it compared to its complexity (especially the
complexity required to address the valid raised concerns). But I'm still
very open minded - and I've got half of a firefox implementation on my
back burner to try and add to the experience-gathering portion of the
process.

Its quite possible that push will create a disincentive to spriting, and
inlining js/css. Doing that would actually have an improved impact on
caching (presuming push can be adapted to caching - which I think it
can), and fine grained resource reuse.. those things have the potential
to be larger net wins for the web than the 1 RTT per page load push
typically yields.

>  The main concern I have is with regards to treating push as an
> optional feature / extension. As many of us have stated repeatedly on
> this mailing list, many things that are optional simply become
> unusable in real, public deployments.
> 
> 
>         
>         --Martin
>

---

From: "Safruti, Ido" <[email-masked]>
Date: Thu, 7 Jun 2012 12:22:55 -0500

I believe we should keep it open for now, as clearly there is some work done on that front, and we should wait and see initial results.
We are also looking at this as a potential way to eliminate a roundtrip which is currently required in any other suggestion (where the client initiates the requests) - between the page and the embedded resources.

From: "William Chan (陈智昌)" <[email-masked]<mailto:[email-masked]>>
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: Mike Belshe <[email-masked]<mailto:[email-masked]>>, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Some thoughts on server push and client pull

On Thu, Jun 7, 2012 at 9:54 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Can you clarify what you mean by new protocol semantics? Does multiplexing count as a new protocol semantic? What's your proposed scope?

I understand the desire to split out server push into a separate draft / extension. If we don't have data to support push, then by all means we should drop it. The main concern I have is with regards to treating push as an optional feature / extension. As many of us have stated repeatedly on this mailing list, many things that are optional simply become unusable in real, public deployments.

--Martin

---

From: Roberto Peon <[email-masked]>
Date: Thu, 7 Jun 2012 14:33:12 -0700

Server push should exist to:
1) Allow elements which would have been inlined to be identified *and
prioritized* separately.
2) Allow content (i.e. website) creators to make some mistakes w.r.t.
resource ordering, and not have the users be severely penalized, which is
what happens with inlining today.
3) Reduce bandwidth:
  a) In cases where the client can advertise elements in the cache which
are associated with the current request, the server could not send those
resources. This would be a strict improvement over inlining.
  b) Even in cases where the client doesn't advertise elements, if the
client closes the streams before the server has sent all the bytes, there
will be a reduction in bytes sent as compared to inlining.

Note I didn't say that it reduces an RTT as compared to HTTP. Rather, it
either:
  1) where the resources were cached it can save multiple RTTs.
  2) Ignoring cache effects it is strictly equivalent to *good* inlining,
where you've put the important resources at the appropriate place in the
document.

Server push is simply better inlining, supported at the layer where it
should be :)

What is the purpose of HTTP? Answering this question seems relevant in
figuring out what the scope is...
-=R

On Thu, Jun 7, 2012 at 10:22 AM, Safruti, Ido <[email-masked]> wrote:

> I believe we should keep it open for now, as clearly there is some work
> done on that front, and we should wait and see initial results.
> We are also looking at this as a potential way to eliminate a roundtrip
> which is currently required in any other suggestion (where the client
> initiates the requests) - between the page and the embedded resources.
>
>
> From: "William Chan (陈智昌)" <[email-masked]>
> To: Martin Thomson <[email-masked]>
> Cc: Mike Belshe <[email-masked]>, Gabriel Montenegro <
> [email-masked]>, "[email-masked]" <
> [email-masked]>

---

From: Alek Storm <[email-masked]>
Date: Thu, 7 Jun 2012 18:12:16 -0500

Hi Jonathan,

On Thu, Jun 7, 2012 at 4:45 PM, Jonathan Silvera <[email-masked]>wrote:

>  *I believe the client can achieve the same effect in SPDYv3 by sending a
> GOAWAY frame, indicating that the other endpoint must not open any new
> streams:*
>
> **·         **There is still data waste by the SYN stream sent to the
> client and also there is nothing on the SPDY spec preventing the server
> from sending data immediately after they send the SYN stream when doing
> Push. This would result in unnecessary SYN_STREAM in the best case and on
> unnecessary pushing of data in the worst case.
>
I believe you're conflating GOAWAY with RST_STREAM+CANCEL. The former
prevents the server from sending any SYN_STREAMs in the first place, while
the latter resets individual streams after their SYN_STREAM has arrived at
the client.

> ****
>
> **·         **From reading the SPDY spec, it seems GOAWAY affects the
> connection. However, there are still valid resources that the client would
> need from the server. Would controlling server push this way require the
> server to add additional logic to continue to serve additional requests on
> the connection, while adding state on the server side to not push
> additional content on subsequent requests when the client has sent a GOAWAY
> message? I am not clear on  how GOAWAY due to a client rejecting Push would
> differ from normal GOAWAY behavior on both client and server.
>
GOAWAY is asymmetric - only the receiving endpoint is prohibited from
opening new streams. In addition, one GOAWAY will suffice to prevent the
server from pushing streams for all future requests on the connection, not
just ones currently open. This state can be reset by opening a new
connection to the server.

> ****
>
> **·         **The SPDY spec, appropriately, does not make GOAWAY
> mandatory. This means that clients that do not implement GOAWAY could still
> have data pushed to them.
>
I'm a bit confused by this. Unless otherwise indicated, all parts of the
spdy/3 spec are mandatory. We have specifically provided a way for a client
to tell the server not to open any push streams. If the client only
partially (and therefore, incorrectly) implements the specification, what
are we to do about it?

> ****
>
> **·         **Overall  it seems that having the client control PUSH
> behavior is cleaner and is more efficient from a bandwidth perspective.
>
Agreed.

> ****
>
> ** *I proposed a detailed system of cache control for pushed resources on
> the spdy-dev mailing list, before I knew of the existence of this list. I
> plan to post it here soon:*
>

Since server push has been a popular topic in the past 24 hours, I
re-prioritized finishing the proposal and sent it to the list a few hours
ago. You can read it at
http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0514.html,
although since some of the formatting has been mangled, I recommend an
email client for an optimal proposal-reading experience. Feedback is most
welcome, but should probably be posted in that thread.

> **
>
> **·         **Great to hear that you are thinking about this. We believe
> that is something that needs to be added to the Push spec. It would
> probably require the client to keep track of resources previously
> downloaded (no data on first navigation to a site) when visiting a top
> level page and advertising the URL for the cached resources, along with the
> corresponding cache validators as part of the top level request. The server
> would then have to explicitly confirm to the client, which cached resources
> are valid in addition to initiating SYN streams for the content that it is
> going to push.
>
There is no need to transmit the URI in addition to the cache validators,
as long as a new restriction is added to entity tags: they must be unique
among different URIs. I will add this to the proposal.

>  ****
>
> **·         **If you are thinking about something similar, it would be
> good to think about how to minimize data transferred on the wire for valid
> cached resources. In the above model, the client has to send the URL +
> cache validators and the server has to send back the URL to explicitly
> inform the client that the cached resource is valid. The net effect is that
> one additional header with a URL (per valid cache resources) is
> transferred, when compared to the proposed “Smart Client Pull” model.
>
My proposal only requires sending the cache validators for subresources,
not their URIs. Additional bandwidth savings may be accrued by setting the
"push-if-invalidated" cache control directive, if all subresources are
still fresh.

 *Pushed content is likely to be that which is required to be present at
> page load in the first place. Pushed CSS stylesheets would prevent flashes
> of unstyled content (FOUC), and pushed scripts that trigger on page load
> would be able to execute before the user is able to interact with the page:
> *
>
> **·         **Our concern here is that in order to completely prevent the
> race condition, the top level page data is serialized behind SYN stream for
> all pushed dependencies.
>
I'm afraid I don't understand this sentence. Can you rephrase?

>  ****
>
> **·         **As you mention the pushed dependencies will **likely** be
> only resources required to load the page. We take it a step further and
> recommend that the server only push critical resources that would block
> page load, since there are lower priority resources on webpages that do not
> affect the user experience. Unfortunately we cannot guarantee that will be
> case in practice.  The effect of misconfigured servers  that push content
> not used on the top level page or push extremely large number of resources,
> is that we end up blocking all data for the top level page on these SYN
> streams and without the first bits of data, the user will be staring at a
> blank screen.
>
I agree, and I think this recommendation should go into the spec. We can
only hope that server admins will err on the side of pushing too few
resources, rather than too many.

> ****
>
> ***Mozilla (and Chrome, I believe) already interpret rel=prefetch as
> conflict:*
> **·         **Our original spec was using the rel=subresource type,
> however we ended up changing it because rel=subresource is not currently
> included in the IANA (
> http://www.iana.org/assignments/link-relations/link-relations.xml) list
> of link relation assignments. We figured pursing an extension to an already
> defined link relation, to be faster than defining a new one. It would be
> great to hear what the veteran standard folks on this list think about this.
> ****
>
> **·         **We interpreted the difference between rel=subresource and
> rel=prefetch as mostly that of priority and saw nothing on the spec
> preventing clients from pre-fetching resources for the current  webpage. It
> would be great to understand if other browsers do not use rel=prefetch to
> bypass rendering/parsing delays. ** **
>
> **·         **We are not sure who has implemented rel=subresource, so it
> would be good to also hear thoughts of other browser vendors about removing
> the distinction between rel=subresource and rel=prefetch.
>
I think they should remain separate. Merging them means we're going to have
to pick one definition - if we pick subresource's, then servers will be
unable to notify the client of resources relevant to *future* requests,
since the client will immediately attempt to fetch them, wasting bandwidth.
Picking prefetch's current definition would present analogous problems.
You're right, the opinions of browser vendors would be helpful here.

Thanks for the detailed reply - this is a great discussion!

Alek

****
>
> Thanks
>
> ** **
>
> -Jonathan Silvera****
>
> ** **
>
> *From:* Alek Storm [mailto:[email-masked]]
> *Sent:* Wednesday, June 6, 2012 7:29 PM
> *To:* Gabriel Montenegro
> *Cc:* [email-masked]; Matthew Cox; Ivan Pashov; Osama Mazahir; Rob
> Trace; Jonathan Silvera
>
> *Subject:* Re: Some thoughts on server push and client pull****
>
> ** **
>
> [email-masked]> wrote:****
>
>  <snip>****
>
> endpoint must not open any new streams.****
>
> ** **
>
> to post it here soon.****
>
> ** **
>
> Pushed content is likely to be that which is required to be present at
> page load in the first place. Pushed CSS stylesheets would prevent flashes
> of unstyled content (FOUC), and pushed scripts that trigger on page load
> would be able to execute before the user is able to interact with the page.
> ****
>
> ** **
>
> which I believe is already implemented in Chrome.****
>
> ** **
>
> My soon-to-come cache control proposal will obviate the need for
> extensions to the Link header, and would afford more fine-grained control.
> ****
>
> ** **
>
> Alek****
>

---

From: "Safruti, Ido" <[email-masked]>
Date: Thu, 7 Jun 2012 19:40:09 -0600

Hi,

I know this is a long discussed issue when multiplexing (specifically around SPDY): the benefits of one optimized connection vs multiple. However, as we most likely will use TCP as an underlying protocol, using one connection exposes us to packet loss impacts. (It is also true that in cases of packet loss – it may impact all established connections).

Did anyone in this forum explored implementing something like link aggregation (or connection aggregation)?
We can have an upgrade mechanism where the server and client can negotiate adding a connection to their channel.
The server can publish, or announce that it supports it, and the client can try to establish an additional connection with some identification/verification, and only once this is verified the channel could be "upgraded" to utilize the additional connection.
Basically establishing link aggregation.
If the upgrade isn't supported, or won't work, we can always remain with a single connection. (and we know it may break in some connection with loadbalancers, or if we can't assure server stickiness).

Using such a mechanism we can ensure better redundancy and recovery mechanisms, but still dramatically reducing the number of connections.

I would be happy to know what people think.

- Ido

---

From: Mike Belshe <[email-masked]>
Date: Thu, 7 Jun 2012 18:46:44 -0700

I'm excited to hear from Google, Yahoo, Tornado, and Cotendo/Akamai that
there is research into server push.  I see no reason to cut it when it is
actively being worked on; my proposal to cut was based on the belief nobody
was trying.  I stand corrected!

To those against the more speculative nature of server push features:  We
won't get another shot at protocol semantics for 15 years.  So, if there is
real work ongoing here, we should let it go further.

To those that are doing research:  Please keep in mind that time is short.
 The rest of the protocol is ready to move forward now, and the choices we
make can be greatly changed based on whether or not push is included as
part of the core.

To mnot:  Perhaps at the next meeting we can discuss some timeframes around
various concepts like server push so that those doing implementations can
have some guidance for dates.

Mike

On Thu, Jun 7, 2012 at 4:12 PM, Alek Storm <[email-masked]> wrote:

>>  *I believe the client can achieve the same effect in SPDYv3 by sending
>> a GOAWAY frame, indicating that the other endpoint must not open any new
>> streams:*
>>
>> ** *I proposed a detailed system of cache control for pushed resources
>> on the spdy-dev mailing list, before I knew of the existence of this list.
>> I plan to post it here soon:*
>>
>
>> **·         **Our concern here is that in order to completely prevent
>> the race condition, the top level page data is serialized behind SYN stream
>> for all pushed dependencies.
>>
> I think they should remain separate. Merging them means we're going to
> have to pick one definition - if we pick subresource's, then servers will
> be unable to notify the client of resources relevant to *future* requests,
>>  Server Push does not require any validation prior to pushing data to
>> the client, which could result in the server sending unnecessary data to
>>  Furthermore, "Server Push" introduces a race condition in which a

---

From: Mike Belshe <[email-masked]>
Date: Thu, 7 Jun 2012 18:50:44 -0700

On Thu, Jun 7, 2012 at 6:40 PM, Safruti, Ido <[email-masked]> wrote:

> Hi,
>
> I know this is a long discussed issue when multiplexing (specifically
> around SPDY): the benefits of one optimized connection vs
> multiple. However, as we most likely will use TCP as an underlying
> protocol, using one connection exposes us to packet loss impacts. (It is
> also true that in cases of packet loss – it may impact all established
> connections).
>
> The server can publish, or announce that it supports it, and the client
> can try to establish an additional connection with some
> identification/verification, and only once this is verified the channel
> could be "upgraded" to utilize the additional connection.
> If the upgrade isn't supported, or won't work, we can always remain with a
> single connection. (and we know it may break in some connection with
> loadbalancers, or if we can't assure server stickiness).
>
> Using such a mechanism we can ensure better redundancy and recovery
> mechanisms, but still dramatically reducing the number of connections.
>
>
I ran experiments using all numbers of connections.  What happens is
exactly what you'd expect with more connections:  compression ratios go
down, SSL overhead goes up, buffering goes up.  Packet loss is the hardest
to understand, as it depends on the correlated vs random packet loss
question.  With random packet loss, it is clear that more connections is
less negatively affected by losses when there are more connections.

If we let the app layer use multiple connections, we'll again prevent the
TCP guys from really being able to optimize.  I hope that we can push
forward on making a single transport connection just-as-good-or-better than
multiple transport connections rather than just throwing buffers at the
problem.

I realize that transports basically never change tho.  Sad!

mike

---

From: "Safruti, Ido" <[email-masked]>
Date: Thu, 7 Jun 2012 21:07:43 -0500

Hi,
I remember reading some ideas about how to enable that on the spdy group.
Obviously there are different security and privacy considerations for doing that, but there are some performance benefits, especially for proxies/intermediate.

I am not sure it is in the scope of HTTP/2.0 and if this mailing list the right place to discuss this?
Is it covered/discussed as part of some other effort?

- Ido

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 7 Jun 2012 20:57:32 -0700

On Thu, Jun 7, 2012 at 6:40 PM, Safruti, Ido <[email-masked]> wrote:
> Hi,
>
> I know this is a long discussed issue when multiplexing (specifically around
> SPDY): the benefits of one optimized connection vs multiple. However, as we
> most likely will use TCP as an underlying protocol, using one connection
> exposes us to packet loss impacts. (It is also true that in cases of packet
> loss – it may impact all established connections).
>
> The server can publish, or announce that it supports it, and the client can
> try to establish an additional connection with some

You might want to take a look at SST
(http://pdos.csail.mit.edu/uia/sst/) and SCTP

---

From: Robert Mattson <[email-masked]>
Date: Fri, 8 Jun 2012 14:15:25 +1000 (EST)

Some quick 2c answers inline, cause I had to :)

Sincerely,
Rob Mattson, MACS (CT), MIEEE

Email: [email-masked]

On Thu, 7 Jun 2012, Safruti, Ido wrote:

> Hi,
> 
> I know this is a long discussed issue when multiplexing (specifically around SPDY): the benefits of one optimized connection vs multiple. However, as we most
> likely will use TCP as an underlying protocol, using one connection exposes us to packet loss impacts. (It is also true that in cases of packet loss ? it may impact
> all established connections).
The effect of packet loss on a connection among many is an exercise in 
probability, it becomes complicated when we think about QoS and RED in the 
mix. RED signals a connection to slow down by dropping packets to trigger 
congestion control/flow back-off responses in the TCP stack.

> Did anyone in this forum explored implementing something like link aggregation (or connection aggregation)?
This is comparable to multiplexing. think of HTTP-MPLEX & web bundles 
against something like Coordinated congestion controle (COCOON). You 
really want a single congestion control algorithm aware of multiple 
connections (response level multiplexing on a single TCP connection).
When you have multiple retransmit buffers that are sizeable because of 
high delay and high bandwidth it might take more segments to trigger 
something like fast retransmit. That is because other segments will be in 
flight delaying the arrival of out of order segments for a TCP connection 
experiencing the loss. Assuming unequal distribution of loss among open 
TCP connections.

> We can have an upgrade mechanism where the server and client can negotiate adding a connection to their channel.
yep. See HTTP-MPLEX. Although you have to wait for the current response to 
arrive before the next stream of responses, but you also reduce head of 
the line blocking with HTTP-MPLEX and also server side response 
prioritisation.

> The server can publish, or announce that it supports it, and the client can try to establish an additional connection with some identification/verification, and
> only once this is verified the channel could be "upgraded" to utilize the additional connection.
HTTP-MPLEX does this in a backwards compatible and transparent manner.

> I would be happy to know what people think.

Thanks for an opportunity to trumpet my own horn, but i'll wait for my 
current caffiene inspired sugar-rush to wear off and i promise to spell 
check my emails in the future and capitalise my 'I's.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 7 Jun 2012 21:22:55 -0700

If the cert you got from the original connection matches the new host you
wish to go to, AND the DNS resolution for that host overlaps with the IP of
the connection you already have, then Chrome will attempt to reuse the
connection.

spdy-dev is probably a better list for discussing this, since this is a
SPDY implementation question.

-=R

On Thu, Jun 7, 2012 at 7:07 PM, Safruti, Ido <[email-masked]> wrote:

> Obviously there are different security and privacy considerations for
> doing that, but there are some performance benefits, especially for
> proxies/intermediate.
>

---

From: "Safruti, Ido" <[email-masked]>
Date: Fri, 8 Jun 2012 02:08:34 -0500

Hi Roberto, thanks for the note,
I know that currently this is the way chrome works.
However, assuming multiplexing will be part of http/2.0, and performance as well I am wondering if we can extend that notion.
Can the server send a validation on an existing SSL connection to validate it is also good for another domain/cert.
Obviously we would want to use another cert for the connection, so that you won't be able to decipher one hosts message by having the cert of another.

Anyhow – I'll move it to spdy dev, but it looks like a TLS issue.

From: Roberto Peon <[email-masked]<mailto:[email-masked]>>
To: Ido Safruti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: multiplexing different hosts on a single SSL connections

If the cert you got from the original connection matches the new host you wish to go to, AND the DNS resolution for that host overlaps with the IP of the connection you already have, then Chrome will attempt to reuse the connection.

spdy-dev is probably a better list for discussing this, since this is a SPDY implementation question.

-=R

On Thu, Jun 7, 2012 at 7:07 PM, Safruti, Ido <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I remember reading some ideas about how to enable that on the spdy group.
Obviously there are different security and privacy considerations for doing that, but there are some performance benefits, especially for proxies/intermediate.

- Ido

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2012 17:16:40 +1000

On 08/06/2012, at 11:46 AM, Mike Belshe wrote:

> I'm excited to hear from Google, Yahoo, Tornado, and Cotendo/Akamai that there is research into server push.  I see no reason to cut it when it is actively being worked on; my proposal to cut was based on the belief nobody was trying.  I stand corrected!
> 
> To those against the more speculative nature of server push features:  We won't get another shot at protocol semantics for 15 years.  So, if there is real work ongoing here, we should let it go further.
> 
> To those that are doing research:  Please keep in mind that time is short.  The rest of the protocol is ready to move forward now, and the choices we make can be greatly changed based on whether or not push is included as part of the core. 
> 
> To mnot:  Perhaps at the next meeting we can discuss some timeframes around various concepts like server push so that those doing implementations can have some guidance for dates.

Well, we need to come to agreement and re-charter, but I'd say we'll be able to have this kind of discussion in Vancouver, yes.

WRT SPDY and server push, I'd suggest keeping it in, but making sure it's separable, so that the decision can be delayed until you have more data.

Regards,

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 8 Jun 2012 00:35:33 -0700

That is one of the ideas we've had for SPDY/4.
Specifically, with name resolution push and with cert data push, a server
could prove that it was authoritative for a domain, and prove that the
client should send requests down the connection.
Of course, name resolution push will be interesting for load balancing,
brownout avoidance, and other goodies, but... I haven't had time to write
up the whitepaper on all this yet. <rueful grin>

-=R

On Fri, Jun 8, 2012 at 12:08 AM, Safruti, Ido <[email-masked]> wrote:

> However, assuming multiplexing will be part of http/2.0, and performance
> as well I am wondering if we can extend that notion.
> Obviously we would want to use another cert for the connection, so that
> you won't be able to decipher one hosts message by having the cert of
> another.
>
> From: Roberto Peon <[email-masked]>
> To: Ido Safruti <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2012 10:27:14 -0700

> WRT SPDY and server push, I'd suggest keeping it in, but making sure it's separable, so that the decision can be delayed until you have more data.

I don't know.  Not to abuse the analogy, but I might like giant wooden
horses and still have an aversion to having strange men inside my city
walls.  Or, from another angle, it's going to be hard enough to get
the simple things right, why add more stuff.  We're here to solve
head-of-line blocking, not to create an standard analogue of the same.

The idea that this is a once-in-a-lifetime opportunity is a fallacy.
If you care about this feature, then make sure that no changes ruin
the protocol such that push couldn't be added.

The trade-offs involved with binary serialization/compression,
multiplexing and the other properties are well enough understood to
retain those.  On the other hand, the unilateral delivery of
unrequested content is not.

--Martin

---

From: Rajeev Bector <[email-masked]>
Date: Fri, 8 Jun 2012 15:33:31 -0500

I am all for the overall concept that stuff that we know needs to be 
sent should be sent early. I am yet to get a warm-and-fuzzy about 
introducing a new paradigm altogether - to accomplish that. With proxies 
in the middle, it definitely adds more things to be thought about.  And 
as others on the thread have opined, getting all the other stuff  *done 
right* (and deployed at scale while we figure out how to inter-operate 
in a mixed world where SPDY and non-SPDY browsers will exist) will be an 
effort in itself.

On 6/7/12 8:46 PM, Mike Belshe wrote:
> I'm excited to hear from Google, Yahoo, Tornado, and Cotendo/Akamai 
> that there is research into server push.  I see no reason to cut it 
> when it is actively being worked on; my proposal to cut was based on 
> the belief nobody was trying.  I stand corrected!
>
> To those against the more speculative nature of server push features: 
>  We won't get another shot at protocol semantics for 15 years.  So, if 
> there is real work ongoing here, we should let it go further.
>
> To those that are doing research:  Please keep in mind that time is 
> short.  The rest of the protocol is ready to move forward now, and the 
> choices we make can be greatly changed based on whether or not push is 
> included as part of the core.
Precisely because time is short - it makes for an even compelling reason 
to decouple the two ! In the sense that since benefits from baseline 
SPDY proposals seem compelling enough - why delay deploying them while 
we wait for the research to be completed.

If the post-research feeling is that "server push" is the best way 
forward (instead of other flattening/pre-fetching alternatives), and the 
benefits seem compelling enough, having another rev in a cpl years 
should be possible (its again a latency vs throughput tradeoff :) ? Mnot ?

Thanks,
Rajeev

>
> To mnot:  Perhaps at the next meeting we can discuss some timeframes 
> around various concepts like server push so that those doing 
> implementations can have some guidance for dates.
>
> Mike
>
>
> On Thu, Jun 7, 2012 at 4:12 PM, Alek Storm <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Jonathan,
>
>     On Thu, Jun 7, 2012 at 4:45 PM, Jonathan Silvera
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         /I believe the client can achieve the same effect in SPDYv3 by
>         sending a GOAWAY frame, indicating that the other endpoint
>         must not open any new streams:/
>
>         ·There is still data waste by the SYN stream sent to the
>         client and also there is nothing on the SPDY spec preventing
>         the server from sending data immediately after they send the
>         SYN stream when doing Push. This would result in unnecessary
>         SYN_STREAM in the best case and on unnecessary pushing of data
>         in the worst case.
>
>     I believe you're conflating GOAWAY with RST_STREAM+CANCEL. The
>     former prevents the server from sending any SYN_STREAMs in the
>     first place, while the latter resets individual streams after
>     their SYN_STREAM has arrived at the client.
>
>         ·From reading the SPDY spec, it seems GOAWAY affects the
>         connection. However, there are still valid resources that the
>         client would need from the server. Would controlling server
>         push this way require the server to add additional logic to
>         continue to serve additional requests on the connection, while
>         adding state on the server side to not push additional content
>         on subsequent requests when the client has sent a GOAWAY
>         message? I am not clear on  how GOAWAY due to a client
>         rejecting Push would differ from normal GOAWAY behavior on
>         both client and server.
>
>     GOAWAY is asymmetric - only the receiving endpoint is prohibited
>     from opening new streams. In addition, one GOAWAY will suffice to
>     prevent the server from pushing streams for all future requests on
>     the connection, not just ones currently open. This state can be
>     reset by opening a new connection to the server.
>
>         ·The SPDY spec, appropriately, does not make GOAWAY mandatory.
>         This means that clients that do not implement GOAWAY could
>         still have data pushed to them.
>
>     I'm a bit confused by this. Unless otherwise indicated, all parts
>     of the spdy/3 spec are mandatory. We have specifically provided a
>     way for a client to tell the server not to open any push streams.
>     If the client only partially (and therefore, incorrectly)
>     implements the specification, what are we to do about it?
>
>         ·Overall  it seems that having the client control PUSH
>         /I proposed a detailed system of cache control for pushed
>         resources on the spdy-dev mailing list, before I knew of the
>         existence of this list. I plan to post it here soon:/
>
>
>     re-prioritized finishing the proposal and sent it to the list a
>     few hours ago. You can read it at
>     although since some of the formatting has been mangled, I
>     recommend an email client for an optimal proposal-reading
>     experience. Feedback is most welcome, but should probably be
>     posted in that thread.
>
>         ·Great to hear that you are thinking about this. We believe
>         that is something that needs to be added to the Push spec. It
>         would probably require the client to keep track of resources
>         previously downloaded (no data on first navigation to a site)
>         when visiting a top level page and advertising the URL for the
>         cached resources, along with the corresponding cache
>         validators as part of the top level request. The server would
>         then have to explicitly confirm to the client, which cached
>         resources are valid in addition to initiating SYN streams for
>         the content that it is going to push.
>
>     There is no need to transmit the URI in addition to the cache
>     validators, as long as a new restriction is added to entity tags:
>     they must be unique among different URIs. I will add this to the
>     proposal.
>
>         ·If you are thinking about something similar, it would be good
>         to think about how to minimize data transferred on the wire
>         for valid cached resources. In the above model, the client has
>         to send the URL + cache validators and the server has to send
>         back the URL to explicitly inform the client that the cached
>         resource is valid. The net effect is that one additional
>         header with a URL (per valid cache resources) is transferred,
>         when compared to the proposed “Smart Client Pull” model.
>
>     My proposal only requires sending the cache validators for
>     subresources, not their URIs. Additional bandwidth savings may be
>     accrued by setting the "push-if-invalidated" cache control
>     directive, if all subresources are still fresh.
>
>         /Pushed content is likely to be that which is required to be
>         present at page load in the first place. Pushed CSS
>         stylesheets would prevent flashes of unstyled content (FOUC),
>         and pushed scripts that trigger on page load would be able to
>         execute before the user is able to interact with the page:/
>
>         ·Our concern here is that in order to completely prevent the
>         race condition, the top level page data is serialized behind
>         SYN stream for all pushed dependencies.
>
>         ·As you mention the pushed dependencies will **likely** be
>         only resources required to load the page. We take it a step
>         further and recommend that the server only push critical
>         resources that would block page load, since there are lower
>         priority resources on webpages that do not affect the user
>         experience. Unfortunately we cannot guarantee that will be
>         case in practice.  The effect of misconfigured servers  that
>         push content not used on the top level page or push extremely
>         large number of resources, is that we end up blocking all data
>         for the top level page on these SYN streams and without the
>         first bits of data, the user will be staring at a blank screen.
>
>     I agree, and I think this recommendation should go into the spec.
>     We can only hope that server admins will err on the side of
>     pushing too few resources, rather than too many.
>
>         /Mozilla (and Chrome, I believe) already interpret
>         rel=prefetch as indicating resources that are likely to be
>         useful in *future* page loads, not necessarily the current one
>         - I would recommend avoiding the naming conflict:/
>
>         ·Our original spec was using the rel=subresource type, however
>         we ended up changing it because rel=subresource is not
>         currently included in the IANA
>         (http://www.iana.org/assignments/link-relations/link-relations.xml)
>         list of link relation assignments. We figured pursing an
>         extension to an already defined link relation, to be faster
>         than defining a new one. It would be great to hear what the
>         veteran standard folks on this list think about this.
>
>         ·We interpreted the difference between rel=subresource and
>         rel=prefetch as mostly that of priority and saw nothing on the
>         spec preventing clients from pre-fetching resources for the
>         current  webpage. It would be great to understand if other
>         browsers do not use rel=prefetch to bypass rendering/parsing
>         delays.
>
>         ·We are not sure who has implemented rel=subresource, so it
>         would be good to also hear thoughts of other browser vendors
>         about removing the distinction between rel=subresource and
>         rel=prefetch.
>
>     I think they should remain separate. Merging them means we're
>     going to have to pick one definition - if we pick subresource's,
>     then servers will be unable to notify the client of resources
>     relevant to *future* requests, since the client will immediately
>     attempt to fetch them, wasting bandwidth. Picking prefetch's
>     current definition would present analogous problems. You're right,
>     the opinions of browser vendors would be helpful here.
>
>         -Jonathan Silvera
>         *From:*Alek Storm [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *Cc:* [email-masked] <mailto:[email-masked]>;
>         Matthew Cox; Ivan Pashov; Osama Mazahir; Rob Trace; Jonathan
>         Silvera
>
>
>         *Subject:* Re: Some thoughts on server push and client pull
>
>         On Wed, Jun 6, 2012 at 8:30 PM, Gabriel Montenegro
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             <snip>
>
>             We don't envision Server push as part of the base HTTP 2.0
>             protocol, but see it as a potentially interesting
>             extension, as long as there is some way for the client to
>             exert some control over when and how it is used. One
>             fundamental requirement is for clients to be able to
>             control “Server Push” behavior via a new opt-in <name TBD>
>             header.  Servers MUST NOT push unrequested data to the
>             client, unless the top level page request <name TBD>
>             header is set to allow “Server Push”.
>
>         I have not verified this, but I believe the client can achieve
>         the same effect in SPDYv3 by sending a GOAWAY frame,
>         indicating that the other endpoint must not open any new streams.
>
>             Server Push does not require any validation prior to
>             pushing data to the client, which could result in the
>             server sending unnecessary data to clients that have some
>             of the pushed resources stored in their cache.
>
>         I proposed a detailed system of cache control for pushed
>         resources on the spdy-dev mailing list, before I knew of the
>         existence of this list. I plan to post it here soon.
>
>             Furthermore, "Server Push" introduces a race condition in
>             which a client could start a new request for data that the
>             server is in the process of pushing, effectively causing
>             the same resource to be downloaded twice. SPDY addresses
>             the race condition by not sending any data (headers are
>             OK) for the top level page, until all of the SYN_STREAM
>             for the dependencies it will push are sent:
>
>             "To minimize race conditions with the client, the
>             SYN_STREAM for the pushed resources MUST be sent prior to
>             sending any content which could allow the client to
>             discover the pushed resource and request it."
>
>             We agree that SPDY's proposal is a good way to mitigate
>             the race condition in Server Push without introducing
>             significant complexity. Unfortunately mitigating the race
>             condition in this manner prevents the server from sending
>             data for the top level page. This could result in
>             user-visible delays.  Whether or not the user will see a
>             delay will depend on what messages (how many and how
>             large) the server is pushing to the client.
>
>         Pushed content is likely to be that which is required to be
>         present at page load in the first place. Pushed CSS
>         stylesheets would prevent flashes of unstyled content (FOUC),
>         and pushed scripts that trigger on page load would be able to
>         execute before the user is able to interact with the page.
>
>             We would like to propose an alternative to Server Push for
>             discussion. This alternative is closely aligned with
>             existing standards and could even work for HTTP 1.1.
>
>             When a server receives an HTTP request for a top level
>             page, the server will generate a list of resources needed
>             to fully load the top level page. The server will send the
>             optimal pre-fetch list to the client, via LINK headers,
>             with a "prefetch" link relation type (defined in HTML5 per
>             http://www.iana.org/assignments/link-relations/link-relations.xml).
>
>
>             The server SHOULD also include the corresponding cache
>             validators for each resource in the pre-fetch list. An
>             extension to the “prefetch” link relation type will be
>             needed to allow cache validator data.
>
>             When a client receives data for a top level page, it will
>             begin processing the top level page response, while
>             simultaneously pre-fetching resources in the pre-fetch
>             list that are not in the client cache or that are cached
>             but invalid, as indicated by the cache validators included
>             in the pre-fetch list. Servers SHOULD only include
>             resources that block loading of the top level page in the
>             optimal pre-fetch list.
>
>         Mozilla (and Chrome, I believe) already interpret rel=prefetch
>         as indicating resources that are likely to be useful in
>         *future* page loads, not necessarily the current one - I would
>         recommend avoiding the naming conflict. SPDY appears to have
>         an ancillary proposal for a rel=subresource with essentially
>         the semantics you describe, at
>         My soon-to-come cache control proposal will obviate the need
>         for extensions to the Link header, and would afford more
>         fine-grained control.
>
>         Alek
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 9 Jun 2012 09:20:50 +1000

> unrequested content is not.

Martin,

I'm talking about in the short-to-medium term; i.e., we don't have to decide this *now*, but we very well may in a month or two.

Regards,

---

From: Karl Dubost <[email-masked]>
Date: Fri, 8 Jun 2012 19:43:30 -0400

Le 7 juin 2012 à 12:43, William Chan (陈智昌) a écrit :
> * To my knowledge, Amazon is using it in their Silk browser. A proxy that uses server push is a fascinating use case, and it'd be cool to get data on that first.

Do you know in which circumstances they use it? (aka only Amazon services, or on the Web in general)

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software