Re: cache hints and preresolutions

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.


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

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