Re: [whatwg] Opportunistic caching
Ian Hickson wrote: On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? (Sorry for late answer, email has probably been lost...) Thanks a lot for clarification. I was talking with my colleague about it and we both agree it would be useful (and probably more easy to implement) for ANY resource being fetched inside of browsing context associated with an application cache to opportunistically cache it and not just do it for results of navigation, i.e. top-level document, iframe source and frame source. A set of pictures/icons/css styles could be easily cached this way w/o explicitly listing them in the manifest. At this point it would be good to say what really is intention/motivation of opportunistic caching itself. Maybe I am missing the purpose and potentially open a security hole or a kind of attack this way. Honza Bambas
Re: [whatwg] Opportunistic caching
Ian Hickson wrote: On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? Thanks a lot for clarification. I was talking with my colleague about it and we both agree it would be useful (and more easy to implement) for ANY resource being fetched inside of browsing context associated with an application cache to opportunistically cache it and not just do it for results of navigation, i.e. top-level document, iframe source and frame source. A set o pictures/icons/css styles could be easily cached this way w/o explicitly listing them in the manifest. At this point it would be good to say what really is intention/motivation of opportunistic caching itself. Maybe I am missing the purpose and potentially open a security hole or a kind of attack this way. Honza Bambas
Re: [whatwg] Opportunistic caching
On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
