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

[Michael Nordman]

A CORS based answer to this would work for the folks that have
expressed an interest in this capability to me.

cc'ing some other appcache implementors too... any thoughts?


On Wed, Jan 26, 2011 at 12:28 PM, Michael Nordman <michaeln at google.com> wrote:
> 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/
>>
>