nginx spdy server hint

[CM Fields]

This is just a quick follow up on this thread of "server hint" for
those interested.

webtide.com has implemented SPDY/3 with server push on some of their
hosts. From the following link it looks like SPDY/3 with server push
will allow a client to deny a server push using a GOAWAY call. So, if
the server is pushing a jpg and the client already has it then the
client can stop the transfer. This method may negate the need for a
server hint entirely and save a few round trip times (RTT).

This is a quote from the article:

"Now you might be wondering what happens if the browser has the
resources already cached? Aren’t we sending data over the wire which
the browser actually already has? Well, usually we don’t. First we use
the if-modified-since header to identify if we should push sub
resources or not and second the browser can refuse push streams. If
the browser gets a syn for a sub resource it already has, then it can
simply reset the push stream. Then the only thing that has been send
is the syn frame for the push stream. Not a big drawback considering
the advantages this has."

http://webtide.intalio.com/2012/06/spdy-we-push/

If webtide is correct with their implementation we should be able to
make a best guess about the client cache and server push data to them
to significantly reduce load times. If we get the guess wrong and the
client already has the data the client can stop the transfer saving
bandwidth.

BTW, just made patch.spdy-48.txt  live on our servers and everything looks fine.

On Tue, Jul 24, 2012 at 5:48 PM, CM Fields <cmfileds at gmail.com> wrote:
> From what I understand using the "Link" header with the rel=prefetch
> directive will download the files once the current page is loaded and
> the client connection is idle. This is to pre-load files that the
> client may request later on the site. This option seems to be in
> Firefox only and available for a few years now.
>
> The Google docs for the "Link" header with the rel=subresource
> directive seems to tell the client the files listed are to be
> downloaded immediately as they are going to be using on the current
> page rendering. In theory the client could ask for the index.html and
> the server would send the index.html with the rel=subresource headers
> for other jpgs. The client would then immediately ask for the jpgs, if
> not already in its cache, instead of decompressing the index.html and
> parsing the file to discover the same pictures.
>
>    http://www.chromium.org/spdy/link-headers-and-server-hint
>
> I did a few tests with the following headers which I found searching
> the google dev docs. I tested the headers against the latest Firefox
> 17.0a1 and Chrome 22.0 and nothing seemed to make any difference
> according to the browser's development tool timings.
>
> add_header  X-subresource "image/jpeg;/image1.jpg;;
> add_header  Link "</image1.jpg>; rel=subresource";
>
> They probably just are not implemented in the browsers at this time.
>
> On Tue, Jul 24, 2012 at 3:33 PM, Valentin V. Bartenev <ne at vbart.ru> wrote:
>> On Tuesday 24 July 2012 22:55:57 Valentin V. Bartenev wrote:
>>> On Tuesday 24 July 2012 22:36:19 CM Fields wrote:
>>> > Thanks for the clarification.
>>> >
>>> > When I read through the SPDY documents up to version 4 I saw no
>>> > mention of server hints at all. I thought I must have missed something
>>> > since every news or review article I read mentions SDPY hints, but no
>>> > one ever had an example.
>>>
>>> Seems it's a browser specific feature. It isn't related to SPDY, or nginx.
>>>
>>>  * http://http://tools.ietf.org/html/rfc5988
>>>  * https://developer.mozilla.org/en/Link_prefetching_FAQ
>>>
>>> You can try:
>>>
>>>     add_header Link "</images/big.jpeg>; rel=prefetch";
>>>
>>> with Firefox.
>>>
>>
>> I've just test it myself. It works well with my Firefox 14 on both HTTP and
>> HTTPS (pure or over SPDY). But I also found that Firebug doesn't show these
>> prefetched requests on the Net tab.
>>
>> And I had no luck with Chromium 21.
>>
>>  wbr, Valentin V. Bartenev
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx