14704 2011-11-05 21:38:30 +0000 appcache: allow a manifest to be identified by something other than its URL 2011-12-07 21:10:26 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC All RESOLVED NEEDSINFO P2 normal --- 1 annevk ian adrianba blizzard eoconnor ian karl+w3c michaeln mike public-html-admin public-html-wg-issue-tracking tobie.langel public-html-bugzilla oldest_to_newest 59659 0 annevk 2011-11-05 21:38:30 +0000 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.) 59660 1 michaeln 2011-11-05 21:44:42 +0000 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 59681 2 karl+w3c 2011-11-07 15:55:27 +0000 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? 59684 3 annevk 2011-11-07 16:31:33 +0000 No, because as far as the server is concerned the resource exists permanently. See the URL for an explanation of fingerprinting. 59685 4 karl+w3c 2011-11-07 16:48:22 +0000 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. 59880 5 ian 2011-11-11 00:24:38 +0000 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. 59933 6 karl+w3c 2011-11-11 19:50:40 +0000 Ian: Ah good point. I would like to see someone from facebook currently using appcache comment on that issue. 61130 7 ian 2011-12-07 21:10:26 +0000 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.