And actually there's another small issue to leave the browser or webkit cache to do the revalidation of the freshness: when it's offline they just cannot do it, and it will quite possibly return the expired resource. So when it's offline, we will always get the "fallback namespace" item instead of its mapping "fallback entry", until the cache is cleared.
Or maybe we can check the expire warning as described in chapter 14.46 of RFC2616, but not sure whether http stack will set that warning for expired items. -----Original Message----- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Lianghui Chen Sent: Tuesday, July 13, 2010 11:55 AM To: Maciej Stachowiak Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application > (b) Revalidating cached items once their freshness lifetime expires. But this will create dependence on the http stack cache implementation? And for some hosting services, the site might not allow the web application to change the http headers in the response? -----Original Message----- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Tuesday, July 13, 2010 11:41 AM To: Lianghui Chen Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application On Jul 13, 2010, at 8:14 AM, Lianghui Chen wrote: > Hi, I have asked this same question in (wha...@lists.whatwg.org), but haven't > got many responses, so I want to ask here again. > > In spec HTML5 for offline web application > (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter 6.6.6, > item 3, 4, 5 state that for resources that is in online whitelist (or has > wildcard whitelist), or fallback list, it should be fetched "normally". > > I would like to know does it mean the user agent (browser) should bypass its > own caches (besides html5 appcache), like the WebKit cache and browser http > stack cache? As the spec is currently written, I think the browser should not bypass its own caches. Other caches should have their normal behavior, and will revalidate once the freshness lifetime of the resource expires. > > If we don't, like WebKit (and Opera) doing now, once browser starts with > network connection, it won't detect network connection loss, which happened > not that common for a PC but common for a mobile device. And it will > effectively defeat the intention of "fallback" resources in a offline web > application, as the content for a "fallback namespace" from cache will be > used, instead of the content of its mapping "fallback entry". Clients have other ways to detect loss of connection: (a) platform-specific APIs that track the state of network interfaces. (b) Revalidating cached items once their freshness lifetime expires. That being said, if you think there is a problem with the spec, you should report it to the W3C Web Apps WG or the WHATWG. Regards, Maciej --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
