804060 - Need to ensure that captive portals don't destroy appcached apps

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure what our current implementation does, so the first step in this bug is to get clarity in that.

What we need to do is to ensure that if a user has an appcached app installed, and is currently behind a captive portal that he/she hasn't logged in to yet, that if we check for updates we don't blow away the cached resources or otherwise behave as if the app has changed.

What does the spec say to do here?

Comment 1

[Honza Bambas (:mayhemer)]

(In reply to Jonas Sicking (:sicking) from comment #0)
> What does the spec say to do here?

More what the update mechanism says here: the first request we do when updating is request for the manifest.  If content of the manifest doesn't apply to the spec, i.e. it doesn't contain the "CACHE MANIFEST" heading line, then we ignore the load and (w/o any modifications to the current cache) cancel the update.  There is just window.applicationCache.onerror event fired, AFAIK.  

We also still check for "text/cache-manifest" MIME type, but that has been removed from the spec and we have an r+'ed but just still not landed patch to remove that check in bug 715809.

Only problem would be if the portal returned 404 or 410 for the manifest request.  Then we would delete the cache.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Honza Bambas (:mayhemer) from comment #1)
> (In reply to Jonas Sicking (:sicking) from comment #0)
> > What does the spec say to do here?
> 
> More what the update mechanism says here: the first request we do when
> updating is request for the manifest.  If content of the manifest doesn't
> apply to the spec, i.e. it doesn't contain the "CACHE MANIFEST" heading
> line, then we ignore the load and (w/o any modifications to the current
> cache) cancel the update. There is just window.applicationCache.onerror
> event fired, AFAIK.  

I assume that it means that we then keep using the cache that we have?

Do we use this behavior for network errors too? For example if the manifest is located on a https server then a captive portal might end up causing ssl errors.

> Only problem would be if the portal returned 404 or 410 for the manifest
> request.  Then we would delete the cache.

I'm not terribly worried about this since I don't think 404 errors would happen that often from captive portals.

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Jonas Sicking (:sicking) from comment #2)
> I assume that it means that we then keep using the cache that we have?

Yes.

> 
> Do we use this behavior for network errors too? For example if the manifest
> is located on a https server then a captive portal might end up causing ssl
> errors.

Yes, network error means "do nothing, affect nothing".

> 
> > Only problem would be if the portal returned 404 or 410 for the manifest
> > request.  Then we would delete the cache.
> 
> I'm not terribly worried about this since I don't think 404 errors would
> happen that often from captive portals.

Unless badly administrated.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, I don't think this is a blocker then.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I think this is a blocker (blowing away apps people have paid for) but sounds like WFM.

Please reopen if you think there's anything left to do here.