Re: [resource-hints] first spec draft

On 13 Jul 2014, at 8:54 pm, Ilya Grigorik <igrigorik@google.com> wrote:

> If a resource is not cacheable, even on a browser, it shouldn’t be prefetched/pre-rendered. You may need heuristics when you do this unilaterally, but when someone enters an explicit hint into the page, I think the requirement is on them to ensure it’s cacheable.

To be clear, in HTTP "cacheable" has a specific meaning - that the response can be stored in a cache, not necessarily that it can be used to satisfy a given request. See RFC7234 section 3.


> History lists come to mind and I'd argue that pre{fetch,render} belong in that same bucket:
> http://tools.ietf.org/html/rfc7234#section-6 

Sort of, although I'm not sure they're something we want to emulate; their behaviour has been notoriously muddled, historically.

I think a better way to think of them is in the layer between the HTML parse and the fetch [1]. For example, if a page has 30 links to an image, it'll use one fetch to satisfy all 30 IMG tags, even if the response has no-store [2]. That's where, conceptually, this sort of thing lives, I think.


> "no-store" seems like the right directive that would/could abort a pre{fetch,render}. That said, afaik, the implemented browser behavior for no-store differs even there for history lists, and the HTTP spec language is (intentionally) loose.. Mark, any thoughts or suggestions?

Not sure yet, but I feel like the answer should be the same for this and HTTP/2 server push, which *is* defined in terms of the caching model, although it's less clear how browsers handle this particular use case. Probably best to loop in folks like Patrick, Will, etc.


> As an aside, a scan over recent HTTP Archive run shows that ~24% of HTML responses advertise "no-store".

Saw that. Not surprising, considering how much "dynamic" HTML there is out there...


1. http://fetch.spec.whatwg.org
2. http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#list-of-available-images

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Thursday, 17 July 2014 05:17:34 UTC