This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14431 - Unclear whether to respect HTTP cache while checking for offline application manifest changes
Summary: Unclear whether to respect HTTP cache while checking for offline application ...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-11 17:23 UTC by Honza Bambas (mozilla)
Modified: 2011-10-25 03:23 UTC (History)
6 users (show)

See Also:

Attachments

Description Honza Bambas (mozilla) 2011-10-11 17:23:35 UTC 
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache

In the chapter "Downloading or updating an application cache", section "Fetching the manifest" it is not explicitly said whether to respect the cache for load of the manifest file from a server during check for manifest's changes.

Gecko implementation requires to send Cache-control: no-cache header, that forces a conditional request to the server or every fetch.  If that header had not been sent during the initial load of the manifest, any change in the manifest file made by a web admin on the server is simply not detected by the UA - Gecko doesn't sent a request and always satisfies from the cache (in this case the offline cache, that is being used in a role of an HTTP cache for the manifest load).

Other browsers seems to bypass the cache completely for the manifest load making it simpler for web admins to setup an offline web app and deploy its new versions.

From the point of view of performance, not respecting the cache is wasting of bandwidth, manifests can be of any size.
Comment 1 Ian 'Hixie' Hickson 2011-10-25 03:22:36 UTC 
The intent here is to leave this up to HTTP. I've updated the spec; it now says that user agents _should_ honour HTTP caching semantics, but _may_ employ cache defeating mechanisms.

In practice this is something I expect UA implementors to tune to fit the balance of reliability and bandwidth efficiency that they feel best represents their users' needs.
Comment 2 contributor 2011-10-25 03:23:08 UTC 
Checked in as WHATWG revision r6749.
Check-in comment: Talk more about HTTP caching semantics in the context of appcache.
http://html5.org/tools/web-apps-tracker?from=6748&to=6749