- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 29 Sep 2009 15:55:00 +0200
On Thu, 24 Sep 2009 10:43:57 +0200, Anne van Kesteren <annevk at opera.com> wrote: > On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman > <michaeln at google.com> wrote: >> For cases where you don't want to, or can't, 'fallback' on a cached >> resource. >> ex 1. >> >> http://server/get/realtime/results/from/the/outside/worldCreating a >> fallback >> resource with a mock error or empty response is busy work. >> >> ex 2. >> >> http://server/change/some/state/on/server/side?id=x&newValue=y >> Ditto > > You could fallback to a non-existing fallback or some such. But if it is > really needed NETWORK should get priority over FALLBACK in my opinion > (or at least the subset of NETWORK that is not a wildcard) so in cases > like this > > FALLBACK: > / /fallback > > NETWORK > /realtime-api > /update > > ... you do not get /fallback all the time. If this change is not made (though I hope it will, since it makes sense) the specification should make it more clear in the writing section (and maybe in parsing too) of the manifest that having both a wildcard and some network URLs does not make sense as the wildcard will always win anyway (per the changes to the networking model section). -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 29 September 2009 06:55:00 UTC