Re: cache hints and preresolutions

> On Jul 7, 2014, at 3:41 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> 
> 
> 
>> On Fri, Jul 4, 2014 at 4:16 AM, Peter L <bizzbyster@gmail.com> wrote:
>> "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."
>> 
>> Good idea. Does Chrome do this currently? 
> 
> I haven't see any code commits for subresource integrity, not sure what the timeline is. 
That's fine. But it seems like the long way around to use a different mechanism to identify version than the HTTP headers that are already supported in browsers' http caches.

>  
>> More importantly server PUSH can not be used for third party resources so it has limited benefit. Let's get this into hints!
> 
> I think we'd want to enforce the same policy here, for all the same reasons. If you want to force a specific version of a third party resource, then you have to host it on own origin. And once you do... just use PUSH.
I don't understand what you mean. The point I'm making is that we can't push the jquery javascript resource used in your subresource example here: https://code.google.com/p/chromium/issues/detail?id=312327. Push is only for same origin sub- resources, which means its potential impact on improving concurrency is much lower than hints. See this blog post for further argument on the importance of prefetching non same domain resources: http://caffeinatetheweb.com/what-makes-the-web-great-also-makes-it-slow/.

> 
> ig
> 
>  
>>> On Jul 3, 2014, at 1:40 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>>> 
>>> 
>>>>> 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
>