Please ignore the first issue I mentioned. I was wrong, there's no such problem with the draft.
On Mon, Jun 13, 2011 at 1:24 PM, Michael Nordman <[email protected]>wrote: > 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). > > >
