-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate Fetch and "AppCache" or remove "AppCache" #151
Comments
Should we mark it deprecated? I believe both Firefox and Chrome have intentions to remove it in the future. In the meantime, it would be nice to at least spec that appcache is disabled when the page is being controlled by a service worker handling FetchEvent. |
It's already marked deprecated. The other issue is https://www.w3.org/Bugs/Public/show_bug.cgi?id=27482 which @jungkees will provide a PR for at some point. |
Ok, sorry for my confusion. |
This is not a perfect rewrite, but provides a much more solid basis for implementations and future work. Follow up fixes will be needed to create a more uniform whole. (See #151, #156, and #158.) PR: #144 Fixes: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24080 * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24613 * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24659 * #95 * #106 * #140
This is not a perfect rewrite, but provides a much more solid basis for implementations and future work. Follow up fixes will be needed to create a more uniform whole. (See #151, #156, and #158.) Fixes: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24080 * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24613 * https://www.w3.org/Bugs/Public/show_bug.cgi?id=24659 * #95 * #106 * #140
F2F: Chrome really needs to drop appcache for HTTP (as do other browsers, as it's a security risk). Then we can start phasing it out further when other browsers ship service worker. We really hope we can drop this before we have (well, @annevk has) to do a ton of spec work about it. |
Thought from @wanderview: Browsers could display "This site may be compromised" on appcache over HTTP. |
…although the above may result in the user just using another browser which doesn't show such scary warnings. |
Can we drop Appcache, though? Are many sites using it? And are there
usecases for it that SW doesn't easily meet? Eg, making mostly-textual
sites work offline?
…--
Bruce Lawson
www.brucelawson.co.uk
www.twitter.com/brucel
|
I think we should aim to. Appcache represents a huge security hole on HTTP, and isn't doing what most authors expect. It's near impossible to make a mostly-textual site work offline with appcache. I'm not against a high-level API for common cases, but a library should guide the way. |
Note that https://www.w3.org/Bugs/Public/show_bug.cgi?id=28009 has a bit more details on the security hole that AppCache provides. |
We just had a security hole pointed out on a user content domain that only exists because of AppCache, especially in Chromium with its CHROMIUM-INTERCEPT feature. This whole AppCache thing was supposed to be an optional enhancement, and it’s long obsolete, and everyone supports Service Workers for at least a year and a half now; so any chance of stirring up discussion towards killing it outright at last? |
Yes, I expect we're able to remove it from the specification somewhere in the first half of 2020, after Chrome and Firefox unship it successfully. (Thanks to @jonathanKingston for starting that whole initiative up again recently!) |
I went searching more carefully for bugs tracking removing it:
Not being inside the community, this information may very well be incomplete or incorrect. |
I know for a fact certain usage of AppCache would require WebKit to continue to support AppCache towards the end of 2020. Also, WKWebView clients on iOS only support app cache, and not service workers. |
The latest plan for appcache in chromium is here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/FvM-qo7BfkI/AvxoE6JpBgAJ |
At the moment it looks like the beginning of June will see AppCache removed in Firefox 77 and the AppCache API will continue to exist but no-op. Does Chrome have an updated plan? |
Here’s the latest in Chromium: https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2B1_fV8fagVuFk%2B_Pb-TGzWyQAVj6A3vwcgjvG6GgLFm6DqTMQ%40mail.gmail.com In essence: reverse origin trial ASAP, and target removal of AppCache for websites without origin trial for M85 (which goes stable in August). |
We're about one release away from AppCache being removed in both Firefox and Chrome. It might be time to rip it out from the spec. Anyway, I stopped by to note that the "ready for post-load tasks" flag is almost entirely used by AppCache. print() is another consumer, but probably that could use "completely loaded" instead. We should probably investigate something analogous to #5796 once AppCache is gone. |
I created #6153 as I'm relatively confident at this point that Chrome and Firefox will succeed in removal. |
The fix for #95 leaves "AppCache" slightly broken based on the expectation that it will be removed. If removing "AppCache" is no longer likely a year and a bit from now we should reevaluate and consider defining "AppCache" properly in terms of Fetch. (And move parts of the processing model into Fetch, most likely.)
The text was updated successfully, but these errors were encountered: