On 13 Jul 2014, at 8:54 pm, Ilya Grigorik <igrigo...@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 m...@akamai.com https://www.mnot.net/
