Re: cache hints and preresolutions

Hi Peter,

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

Cheers,
Yoav


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