[whatwg] AppCache-related e-mails
michaeln at google.com
Thu Aug 4 15:34:19 PDT 2011
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...
> / 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...
> When the fallback is used in this case the manifest url will be interpreted as /file.manifest
> 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.
So i think including Origin:<manifestUrlOrigin> when fetching all resources
to populate an appcache could be the source of some subtle bugs.
More information about the whatwg