- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 26 Jan 2011 09:50:38 +0100
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 00:50:38 UTC