Issue metadata
Sign in to add a comment
|
Application cache partially used on http
Reported by
m...@infologic.fr,
Oct 29
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce the problem: 1. have a website that uses application cache served on http. 2. open it in an old version of chrome (pre 70) 3. the application is cached 4. update chrome version (70) 5. open the same application What is the expected behavior? all files should be downloaded from upstream. What went wrong? The main page was loaded from disk cache (logs from network tab): Request URL: http://xxxxx/app.html Request Method: GET Status Code: 200 OK (from disk cache) Remote Address: xxxx Referrer Policy: no-referrer-when-downgrade HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Disposition: inline;filename="app.html" Accept-Ranges: bytes ETag: app.html_3496_1539759456273 Last-Modified: Wed, 17 Oct 2018 06:57:36 GMT Expires: Wed, 17 Oct 2018 06:57:36 GMT Pragma: no-cache Cache-Control: no-cache, must-revalidate Content-Range: bytes 0-3495/3496 Content-Encoding: gzip Content-Type: text/html;charset=utf-8 Content-Length: 1178 Date: Wed, 17 Oct 2018 06:57:36 GMT The other ressources were fetched from upstream : Request URL: http://xxx/starter.js Request Method: GET Status Code: 403 Interdit Remote Address: xxx Referrer Policy: no-referrer-when-downgrade HTTP/1.1 403 Interdit Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Language: fr Content-Length: 1011 Date: Mon, 29 Oct 2018 15:15:09 GMT Did this work before? Yes Chrome 69 Does this work in other browsers? Yes Chrome version: 70.0.3538.77 Channel: stable OS Version: 10.0 Flash Version: The problem is that the ressources are only available while connected to our app. On first login (cookie based), the user is redirected to this page. He is connected, hence the ressources are available, and cached. If the app.html is accessed for the first time while not logged in, it is redirected to the login page (302 redirect). If the application is cached and not logged in, the application is loaded, and the code redirects to login page. Now, when not logged in, the main page is still loaded from cache, but not the ressources (403 error). So, we neither can redirect (302 http) while accessing the main page (as it is loaded from cache), nor do it by code (as the ressources are not loaded from cache and not loaded from upstream because the user is not logged in). The only solution is to "clear site data". It will be difficult to tell that to our customers. Is there any alternative solution?
,
Oct 30
,
Oct 31
Tested the issue on reported chrome version #70.0.3538.77 using Windows 10 by following below steps. Steps: ===== 1.Launched chrome. 2.Navigated to "http://xxxxx/app.html". 3.Observed that "The site cannot be reached". Attached screencast for reference. @reporter: Could you please provide any sample file or URL that reproduces the issue so that it would be really helpful for triaging the issue. Thanks.!
,
Oct 31
Well, to help to reproduce.
Here is a test case.
have a small nginx (or similar) with the following conf:
server {
listen 0.0.0.0:8888 default_server;
location /app.html
{
if ($cookie_auth != "hello")
{
return 302 /index.html;
}
}
location /starter.js
{
if ($cookie_auth != "hello")
{
return 403;
}
}
}
the files are :
index.html
==========
<html>
<head></head>
<body>
<button id="login">Login</button>
<button id="logout">Logout</button>
</body>
<script>
document.getElementById("login").addEventListener("click",function (e) {
document.cookie="auth=hello";
location.href="app.html";
});
document.getElementById("logout").addEventListener("click",function (e) {
document.cookie="auth=";
});
</script>
</html>
app.html
========
<html manifest="test.appcache">
<head>
<style>
body { background-color:red;color:white;font-size:36px;text-align:center}
</style>
</head>
<body>
Not good =(
</body>
<script src="starter.js"></script>
</html>
starter.js
=========
document.getElementsByTagName("body")[0].style.backgroundColor="green";
document.getElementsByTagName("body")[0].innerText="All good";
test.appcache
=============
CACHE MANIFEST
CACHE:
starter.js
NETWORK:
*
-------------------------------
If you open "index.html" on chrome 69 served by http not on localhost, and click on "login", you'll be redirected to app.html, displaying "all good" and cached.
If you refresh app.html, it works.
Update to chrome 70.
if you still have the cookie, you don't have any problem.
But, if you clear the cookie and refresh the page, you'll see "Not good =("
because
- app.html is served from disk cache
- starter.js is neither served by disk cache nor by http.
,
Oct 31
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31
mkwst - what is the behavior for existing caches for non-secure origins with RestrictAppCacheToSecureContexts enabled? I don't see code on the browser side which tests this... ?
,
Oct 31
Hrm. I removed the blink-side implementation, which meant that existing caches would be maintained, but we'd kill off creation of new caches. The goal was to ensure that existing data wouldn't be lost, and to let usage trail off over time rather than killing it entirely overnight. That was intentional. It surprises me that we end up in an intermediate state whereby the document is loaded from cache, but the subresources aren't. I thought we'd end up in one state or the other. I won't be able to look at this until next week when I'm back at the office. jsbell@, wanderview@: perhaps one of you would have time to evaluate the current behavior, and determine whether we need to roll back the behavior via Finch?
,
Nov 1
As per comment#1, the root cause of the issue seems to be identified and active investigation of the issue is being performed. Hence removing the Needs-Bisect label. Please feel free to add the same if required. Thanks.!
,
Nov 2
Chrome 69 was branch 3497, which was created at 576753. Downloads: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/576753/ https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/576753/ https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/576753/
,
Nov 8
I think Victor is the lucky owner of appcache at the moment. (I don't completely understand #c9, though...)
,
Dec 3
Is anyone aware of a workaround for this issue? We have a web app that is using AppCache (yes, I know we need to move to service workers) over HTTP (nonsecure) on Android. As of release v70, our application shows a warning in the console that AppCache will not be used over insecure context. We would be OK with this except that the main index page is still loading from AppCache. Which is preventing us from moving users off of AppCache as we need the main index page to load so AppCache sees that we have removed the manifest attribute. If no workaround is available, is there any ongoing work or assistance we can provide in order to help move this issue along?
,
Dec 4
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by wanderview@chromium.org
, Oct 29