[whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.

[Michael Nordman]

On Mon, Feb 7, 2011 at 6:18 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 04 Feb 2011 23:15:44 +0100, Michael Nordman <michaeln at google.com>
> wrote:
>>
>> Just want to wake this thread up and say that I still see CORS as a
>> good fit for this use case, and I'm curious Jonas about what you think
>> in light of my previous post?
>
> I think Jonas does have a point. There are side effects to setting the CORS
> headers. I am not sure whether these are bad or good, but if people approach
> this from the idea of getting cross-origin caching to work they might not
> consider them.
>
> I.e. once CORS is used on those resources they can be read using
> XMLHttpRequest. And once we make further changes to the platform
> cross-origin images can be read via <canvas>, etc.

The side effect with appcaching is that the data is persisted locally.
Recipients of CORS response data via XHR can persist that data locally
even w/o the appcache. So if a resource is made CORS'able for the
purposes of XHR, there's no harm in allowing it to be appcached.

Going the other way... if a resource is made CORS'able for the
purposes of appcaching, that has the side effect of making the
resource directly loadable as well. If a developer is not willing to
allow that than those resources should not be made CORS'able.

If you buy that line of thinking, it's OK to make CORS'able resources
appcachable, but that may not be sufficient for all use cases (cases
where a resource should be appcachable but not loadable).