- From: Michael Nordman <michaeln@google.com>
- Date: Wed, 26 Jan 2011 12:28:20 -0800
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/ >
Received on Wednesday, 26 January 2011 12:28:20 UTC