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

[Michael Nordman]

I was alluding to a simple robots.txt like solution with the static
'allow' file, but it seems like CORS could work too, it is more
burdensome to setup due to the additional HTTP headers.

GET /some-resource
Origin: https://acme.com

HTTP/1.x 200 OK
Access-Control-Allow-Origin: * | https://acme.com

Unless the the origin is allowed, the resource will not be added to
the cache and the update will fail.

......
On Wed, Jan 26, 2011 at 12:50 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 25 Jan 2011 23:37:55 +0100, Michael Nordman <michaeln at google.com>
> wrote:
>>
>> Would the public-webapps list be better for discussing appcache
>> feature requests?
>
> It's not a feature drafted in any of the WebApps WG specifications. If you
> want to discuss at the W3C the appropriate place would be the HTML WG.
>
> Also,
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
> might be interesting. (Though you are probably aware of it.)
>
>
>> This could be as simple as the presence of an
>> 'applicationcaching_allowed' file at the top level. An https manifest
>> update that wants to retrieve resources from another https origin
>> would first have to fetch the 'allow' file and see an expected
>> response, and if it doesn't see a good response, those xorigin entries
>> would be skipped (matching today's behavior).
>>
>> The request...
>>
>> GET /applicationcaching_allowed
>> Referer: <manifestUrl of the cache trying  to include resources from this
>> host>
>>
>> The expected response headers...
>>
>> HTTP/1.x 200 OK
>> Content-Type: text/plain
>>
>> The expected response body...
>>
>> Allowed:*
>
> So far we have avoided this type of design as it is rather brittle. Maybe
> CORS can be used?
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>