Re: cache hints and preresolutions

> On Jun 25, 2014, at 9:53 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>
> I have a couple of questions regarding these additions:
> * Caching hints - What is the benefit from adding those? Avoiding a
> conditional request+304 if the resource is cached & stale, but still
> relevant?
>
> Yes! We can eliminate a large % of cache re-validation requests. I am
> working on gathering data on the value of this in terms of round trips
> saved based on our network but it will likely take a few weeks.
>

- stale-while-revalidate [1] allows you to unblock the browser from waiting
on revalidation requests.
- nothing stops the UA from computing and storing the integrity checksum
when it first writes the resource to its cache.. there is no need to load
it and checksum it from disk each and every time.

As far as eliminating revalidation requests... This seems like a use case
for server push: push a 304 response with appropriate CC directives to
inform the browser that it should renew the expiry times of a resource?
Seems like we already have all the necessary bits in place for this.

[1]
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/zchogDvIYrY/SyVwpb8V-6IJ


>  * Preresolution - What is the scenario where you would be forced to go
> through the redirect if you already know the final URL of the redirection
> chain (especially if it's a 301 response)? In other words, why hint it, if
> you could explicitly direct your iframe at it? Is it relevant only to
> appliances that have a hard time modifying the HTML itself?
>
> My specific application (as described here at a high level
> http://caffeinatetheweb.com/baking-acceleration-into-the-web-itself/) is
> based on modifications to PageSpeed so I will be able to re-write the HTML
> itself. However I prefer the use of hints to re-writing complex HTML when
> possible as it is a lower risk operation in general. Does that make sense?
>

Same as above.. You can push a 301 response to the client with SPDY /
HTTP/2.

Granted, we would need to make sure that the browser understands and works
as expected on these 30X pushes.. but otherwise, the right pieces seem to
be there already.

ig

 On Mon, Jun 23, 2014 at 8:32 PM, <bizzbyster@gmail.com> wrote:
>
>> Ilya,
>>
>> Two additions to your doc:
>> https://docs.google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit
>> .
>>
>> Cache hints:
>> We talked about the idea of supplying version information in preload (or
>> subresource) hints via the sub-resource integrity attribute. But I'm not
>> crazy about that idea b/c it means the browser needs to load an object from
>> the browser disk cache and run a checksum on it in order to check whether
>> or not that resource is the same as the one in the preload hint. Why not
>> just allow us to specify cache version information via Last-Modified-Time
>> and/or Etag? This makes it easy and fast to check to see if the cached
>> version is current or not. Perhaps this could be a new attribute (version?)
>> of the LINK header?
>>
>> Preresolutions:
>> Also, it would be great if we could specify the result of DNS lookups and
>> also inline HTTP responses. So, for instance, let's say I have a site
>> called simple.html that has an iframe hosted by a third party site. That
>> third party site includes a URL that always receives a 301 Permanent
>> redirect. It'd be great if we could optimize the loading of the page by
>> simply including that 301 response code and Location header in as a
>> "preresolution" up front along with the other resource hints.
>>
>> Thoughts? Anyone else?
>>
>> Peter
>>
>>
>>
>
>