W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] AppCache FOREIGN entry issues.

From: Michael Nordman <michaeln@google.com>
Date: Mon, 13 Jun 2011 19:39:27 -0700
Message-ID: <BANLkTimfAPmDfzs3EzXnG556crwYwznF+gJ2+tssgzsGJsfSGg@mail.gmail.com>
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 <michaeln at google.com>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).
Received on Monday, 13 June 2011 19:39:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC