Re: Some thoughts on server push and client pull

On Wed, Jun 6, 2012 at 8:30 PM, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

>  <snip>
>
> 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”.
>

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.

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

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