Bug 14704 - appcache: allow a manifest to be identified by something other than its URL
Summary: appcache: allow a manifest to be identified by something other than its URL
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-05 21:38 UTC by Anne
Modified: 2011-12-07 21:10 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2011-11-05 21:38:30 UTC
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.)
Comment 1 michaeln 2011-11-05 21:44:42 UTC
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
Comment 2 Karl Dubost 2011-11-07 15:55:27 UTC
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?
Comment 3 Anne 2011-11-07 16:31:33 UTC
No, because as far as the server is concerned the resource exists permanently. See the URL for an explanation of fingerprinting.
Comment 4 Karl Dubost 2011-11-07 16:48:22 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2011-11-11 00:24:38 UTC
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.
Comment 6 Karl Dubost 2011-11-11 19:50:40 UTC
Ian: Ah good point.

I would like to see someone from facebook currently using appcache comment on that issue.
Comment 7 Ian 'Hixie' Hickson 2011-12-07 21:10:26 UTC
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.