- From: Michael Nordman <michaeln@google.com>
- Date: Thu, 4 Aug 2011 15:34:19 -0700
On Tue, Aug 2, 2011 at 5:23 PM, Michael Nordman <michaeln at google.com> wrote: > 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. > > According to some documentation over at mozilla'land, the value of the Origin header is different depending on the source of the request. https://wiki.mozilla.org/Security/Origin#When_Origin_is_served_.28and_when_it_is_.22null.22.29 So i think including Origin:<manifestUrlOrigin> when fetching all resources to populate an appcache could be the source of some subtle bugs.
Received on Thursday, 4 August 2011 15:34:19 UTC