[whatwg] Cache Manifest: why have NETWORK?

[Anne van Kesteren]

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/