[whatwg] AppCache-related e-mails

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...
>
> 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.