[whatwg] AppCache FOREIGN entry issues.

Mon Jun 13 13:24:31 PDT 2011

1) There's a bug in the draft around FOREIGN entries.

BUG: When updating an existing cache containing FOREIGN entries, the FOREIGN
flag is sticky even if the resource has been modified and is no longer
FOREIGN. The update algorithm (section 6.6.4) should be modified to reset
the FOREIGN flag if a new resource is actually downloaded as part of the
update.

2) There's another rough spot with FOREIGN entries. This one's an awkward
problem with FALLBACK resource being identified as FOREIGN. I'm not sure the
spec is actually clear about how the manifest attribute value of a FALLBACK
entry should be interpreted. A clarification would be good.

Here's a description of the problem from
http://code.google.com/p/chromium/issues/detail?id=82577

ApplicationCache can flag fallback resources as FOREIGN when it shouldn't

Let's say there's a page in the cache to be used as a fallback
resource, refers to the manifest by relative url...

<html manifest='x'>

Depending on the url that invokes the fallback resource, 'x' will be
resolved to different absolute urls. When it doesn't match the actual
manifest url, the fallback resource will get tagged as FOREIGN and
will no longer be used to satisfy main resource loads.

I'm not sure if this is a bug in chrome or a bug in the appcache spec
just yet. I'm pretty certain that Safari will have the same behavior
as chrome in this respect (the same bug). The value of the manifest
attribute is interpreted as relative to the location of the loaded
document in chrome and all webkit based browsers and that value is
used to detect foreign'ness.

The workaround/solution for this is to NOT put a manifest attribute in
the <html> tag of the fallback resource (or to put either an absolute
url or host relative url as the manifest attribute value).