Bug 14705 - appcache: SOP requirement for cache manifest files should be relaxed (at least) by CORS.
appcache: SOP requirement for cache manifest files should be relaxed (at leas...
Status: RESOLVED WONTFIX
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
PC All
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-05 21:49 UTC by Tobie Langel
Modified: 2013-04-24 16:40 UTC (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobie Langel 2011-11-05 21:49:20 UTC
This enables putting the manifest files on a CDN.
Comment 1 Ian 'Hixie' Hickson 2011-11-11 00:22:15 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: Rejected
Change Description: no spec change
Rationale: It would also enable a hostile open wifi access point to permanently hijack facebook.com to point to evil.example.net, which seems, to put it mildly, problematic.
Comment 2 michaeln 2011-11-11 20:44:58 UTC
Reopening in the hopes of gathering more input about why the SOP for this is a problem and what might be done to resolve it.
Comment 3 Ian 'Hixie' Hickson 2011-12-03 22:23:56 UTC
Reassigning to michaeln as per comment 2. If you gather actionable input, please don't hesitate to reassign this to me so I can study it further.
Comment 4 Tobie Langel 2012-01-24 22:14:21 UTC
This was an attempt at solving use-case #2 here: http://www.w3.org/community/fixing-appcache/2012/01/18/appcache_use_cases/#use_case_2

Allow an application hosted on a cluster of servers to be easily updated
An application is hosted on a cluster of servers behind a non-sticky load balancer. It is updated daily. Even though all servers are not updated instantly and two versions of the application co-exist for a while, it is possible to update the application without risking to have an out-of sync version of the application (e.g. manifest file and assets of the latest version combined with a Master Entry of the previous version) or to need to invalidate the cache to avoid such issues.

Probably would have been more useful to provide the use case upfront rather that potential solutions.
Comment 5 contributor 2012-07-18 04:37:55 UTC
This bug was cloned to create bug 17802 as part of operation convergence.
Comment 6 Robin Berjon 2013-01-21 16:00:43 UTC
Mass move to "HTML WG"
Comment 7 Robin Berjon 2013-01-21 16:03:21 UTC
Mass move to "HTML WG"
Comment 8 Anne 2013-02-07 11:16:50 UTC
Ian, why could a wireless not do that anyway over HTTP without TLS? And if there is TLS, there is no problem to begin with.

You still need CORS because of the update events (I think). You also need a new crossorigin attribute on <html> to control the details.
Comment 9 Robin Berjon 2013-04-24 16:40:55 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: Rejected
Change Description: none
Rationale: Supporters of this use case no longer seem to believe it important.