Re: prefer-online vs manifest association

On 21 September 2012 00:04, Andrew Betts <andrew.betts@ft.com> wrote:
> Just found something today which may be obvious and has simply passed
> me by, but really caught me off guard.  It seems that on pages that do
> not reference a manifest and are not themselves in an appcache,
> loading of sub-resources that are appcached may use the appcache, but
> only after checking the network first.

This doesn't add up with my experience. What I've seen is pages that
load without appcache do not use appcache for in-page requests (imgs,
css, js, xhr), even if the requested file existed in an application
cache. This created a problem in the first version of m.lanyrd.com...

1. User visits site with connection
2. Request is made normally, doesn't trigger FALLBACK
3. User loses connection
4. User action results in XHR request
5. XHR request fails (no status code, no FALLBACK)

The above happens even the XHR url is explicitly in an application
cache, or covered by a FALLBACK rule.

The exception to this is child-browsing contexts, which is what you're
seeing with iframes.

>From http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
- "When a cache host is associated with an application cache whose
completeness flag is complete, any and all loads for resources related
to that cache host other than those for child browsing contexts must
go through the following steps instead of immediately invoking the
mechanisms appropriate to that resource's scheme"

> If the page does have a
> reference to the manifest (and is therefore appcached as a master
> entry) or is explicitly appcached by another master, the sub-resource
> is loaded from the appcache *without* a network request.

Yes, if that sub-resource is in the current application cache.
Otherwise it'll make a network request if (in this order) the url is
listed in NETWORK, the url is covered by a FALLBACK prefix, or NETWORK
contains *, otherwise the request fails.

But yeah, iframes are excepted by child browsing context rule.

> Here's an example... *snip*

Hah, yes, good catch, that looks like a bug in Webkit. The iframed
page should behave the same as it would in its own tab.

> Jake - on your flowchart of doom
> (https://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag?slide=81)
> this behaviour doesn't seem to match what you've documented, so I'd be
> interested to know if you think I'm spouting a load of nonsense here.

I've uploaded a bigger version of the diagram
http://www.flickr.com/photos/jaffathecake/8015087167/sizes/o/in/photostream/

The ambiguous parts of the diagram are the two instances of "For each
GET request triggered by the page", which is false for iframes as
they're technically triggered by a different page, an empty iframe
page in the case of your demo.

Received on Monday, 24 September 2012 09:04:39 UTC