833834 - Refetch app caches with https:// manifests to get security info

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect)

Description

[Honza Bambas (:mayhemer)]

To give a complete and good UX after fix of bug 794507 we have to refetch app caches to get the correct sec-info to the cache ASAP.

Solution:
- when we have a cached manifest loaded via a secured protocol (https) that doesn't have sec-info in the cache, prevent offline cache update to use the current appcache version as cache to validate against (simulate first fetch)

However, UX will still be bad since the update won't happen sooner then after the page load.  It means to get valid lock icon user needs to:
- load the page
- wait for the cache update to finish (may take a while, since we do a complete refetch)
- reload the page

Do it a different way may be too complicated.  Like, before we load the main page, check the manifest for the "secured w/o sec-info" condition and prevent load from app cache for the page.  But when user it actually offline or the app source is temporarily unreachable, it may lead to a very bad UX "where the hell has my offline app gone??"

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Honza Bambas (:mayhemer) from comment #9)
> (In reply to Brian Smith (:bsmith) from comment #7)
> > (In reply to Honza Bambas (:mayhemer) from comment #6)
> > How about we change the code for conditional requests so that we never add
> > the conditional request headers if we're doing an offline cache update and
> > the existing entry doesn't have a security-info entry?
> 
> That seems effectively identical to my proposal.  I want to let the cache
> reload on access.  Deleting or artificial invalidating is the same actually.
> However, for the manifest we also have to remove the "hash" metadata to
> prevent seeing the manifest identical even when revalidated.

OK. I don't understand this well enough to have an opinion. The important thing is that we consider all cached content as invalid if it was cached before the fix for bug 794507.

(In reply to Honza Bambas (:mayhemer) from comment #0)
> However, UX will still be bad since the update won't happen sooner then
> after the page load.  It means to get valid lock icon user needs to:
> - load the page
> - wait for the cache update to finish (may take a while, since we do a
> complete refetch)
> - reload the page
> 
> Do it a different way may be too complicated.  Like, before we load the main
> page, check the manifest for the "secured w/o sec-info" condition and
> prevent load from app cache for the page.  But when user it actually offline
> or the app source is temporarily unreachable, it may lead to a very bad UX
> "where the hell has my offline app gone??"

I think this is the best we can do. I agree that we don't want the offline app to stop working due to this error.