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 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...
>
>
>
> 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
> tag of the fallback resource (or to put either an absolute url or host
> relative url as the manifest attribute value).
>
>
>