[whatwg] AppCache-related e-mails

Tue Aug 2 17:23:02 PDT 2011

>
> On Mon, 13 Jun 2011, Michael Nordman wrote:
> >
> > 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).
>
> Or just make sure you always use relative URLs, even in the manifest.
>
> I don't really understand the problem here. Can you elaborate further?
>
>
Suppose the fallback resource is setup like this...

FALLBACK:
/ FallbackPage.html

... and that page contains a relative link to the manifest in its
<html> tag like so...
<html manifest=file.manifest>

Any server request that fails under / will get FallbackPage.html in
response. For example...

/SomePage.html

When the fallback is used in this case the manifest url will be
interpreted as /file.manifest

/Some/Other/Page.html

And in this case the manifest url will be interpreted as
/Some/Other/file.manifest

On Fri, 1 Jul 2011, Michael Nordman wrote:
> >
> > Cross-origin resources listed in the CACHE section aren't retrieved with
> > the 'Origin' header
>
> This is incorrect. They are fetched with the origin of the manifest. What
> makes you say no Origin header is included?

I don't see mention of that in the draft? If that were the case then this
wouldn't be an issue.

I'm not familiar with CORS usage. Do xorigin subresource loads of all kinds
(.js, .css, .png) carry the Origin header?

I can imagine a server implementation that would examine the Origin header
upfront, and if it didn't like what it saw, instead of computing the
response without the origin listed in the Access-Control-Allow-Origin
response header... it just wouldn't compute the response body and return an
empty response without the origin listed in the Access-Control-Allow-Origin
response header.

If general subresource loads aren't sent with the Origin header, fetching
all manifest listed resource with that header set could cause problems.