This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Large server setups use URL fingerprinting for caching. Basically you have the same resource distributed over many servers and the only way to update it is by changing its URL. See also: http://code.google.com/speed/page-speed/docs/caching.html Cache manifests are incompatible with this model by having a URL identify the cache. To address this case we should have a separate identifier, probably tied to the origin of the manifest, that identifies the manifest. In the absence of such an identifier the URL would still identify the manifest. (As an aside, we cannot identify the manifest by its master entries, because they can change over time.)
so effectively the identifier of the appcache would be a 'name' instead of a resource url... thnx for explaining the issue... this makes sense to me
If the URL is stable and on the server side, the web developer are using a 302 temporary redirect to the new URL? Would it not solve the issue?
No, because as far as the server is concerned the resource exists permanently. See the URL for an explanation of fingerprinting.
Anne, I know what is URL fingerprinting. In my previous job, we were using it for some specific big sites. There are many ways do do that. One of the way to do that is to use a timestamp. http://example.org/blabla?yyyymmddhhmmss This answer doesn't make sense in the context of your previous comments: "No, because as far as the server is concerned the resource exists permanently." URL Fingerprinting is specifically used for busting the browser cache in a way which is random. Basically we do not know in advance when it will change. We do that usually when hosting CSS files on a CDN or icons for profiles pictures in a social network for example, where you usually want the photo live forever (Long caching information - Expires in the order of months) and at the same time be able to have the browser to update it when there is a new image. The proposal for a separate identifier is basically recreating a HTTP 302 mechanism.
Why can't the same "live" mechanism used for the root of a domain be used for a manifest? If the URL is not used to identify the manifest, and the content of a given URL is static for all time, how would you know what URL to use to check to see if the manifest changed? Karl: We can't use redirects, the appcache system assumes those are a sign of a captive portal.
Ian: Ah good point. I would like to see someone from facebook currently using appcache comment on that issue.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. See above comments for specific questions.