_Update algorithm should unregister SW on 404 and 410 errors

[jyasskin]

Currently the _Update algorithm says

• If fetching the script fails due to the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, then:
  1. Reject promise with a new NetworkError.
  2. Set serviceWorkerRegistration.updatePromise to null.
  3. Abort these steps.

Both @annevk and @jakearchibald have suggested that all 4xx responses should be interpreted as unregistering the SW instead of as an update failure. AppCache only treates a 404 or 410 as deleting the AppCache, and I think some other responses like 403 may be transient, so I'm only proposing to match AppCache. If y'all think all 4xx responses should unregister instead, I won't argue.

[jakearchibald]

👍 Happy to unregister on 404/410 in line with appcache.

[annevk]

The main reason I suggested 4xx was that in that case the server can be reached and is active but apparently is no longer hosting an accessible service worker in that location.

With your suggested approach HTTP-only sites with a 403 space would be more vulnerable to attacks.

[jyasskin]

This is a proposal for HTTPS sites. Even unregistering on all 4xx errors wouldn't be enough for HTTP sites; see #199 for that.

[piranna]

I would unregister for all 4xx & 5xx errors. If a user agent receive them, both the client and the server are online so it's feasable to receive the updated ServiceWorker in the near future, and during this time the ServiceWorker served resources can be available directly by the server. I would only prevent to unregister the SW after the stated 24 hours life limit if the client is offline.

[annevk]

@jyasskin the same reasoning applies to HTTPS I think, apart from the attacks.

@piranna no, 5xx could be because the server is undergoing maintenance or is under heavy traffic or some such. Makes no sense to unregister there.

[piranna]

@annevk, I didn't take in account that situation. Could it make sense to automatically unregister on any 4xx error, and left th SW untouched until the 5xx error gets fixed so a decision can be done? I think it should fix the problems we are having here...

[annevk]

Yes, that follows from OP and subsequent comments.

[slightlyoff]

Unregistration on 4xx is broken. It is hostile to intermittent data center downtime, etc. If you need this for security, use SSL.

[annevk]

Why would a data center return 4xx in that case and not 5xx?

[jyasskin]

IIUC, restricting to SSL obsoletes this issue.