[Bug 14431] New: Unclear whether to respect HTTP cache while checking for offline application manifest changes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14431

           Summary: Unclear whether to respect HTTP cache while checking
                    for offline application manifest changes
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: hbambas@mozilla.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 11 October 2011 17:23:38 UTC